Yii2 advanced prepare to production - deployment

I have an app in yii2 builded on top the template advanced, but i have a few concerns about how to deploy this app in Production.
Should i run php init again and set production env?
many thanks,enter image description here

If you prepared your Production environment correctly - yes, you should.

Related

Running Strapi in production and version control sync issues

I'm wondering what the best practice is for running Strapi in production. I noticed that Strapi generates new files when a content type is added. This means that the production environment's files will become out of sync with version control. Is there a recommended deployment process? Am I supposed to commit changes from production to my git repo after making changes in the admin?
The file generation which is made primarily by content-type-builder and other settings are disabled in production mode NODE_ENV=production
The admin panel is supposed to be already built on prod, so you only add necessary data into DB based on the given data structure.
TLTR:
Summarizing answer to your question in from github.com/strapi/strapi/issues/1986:
emadicio commented on 20 Sep 2018
If you run your app with NODE_ENV=production you'll notice that plugins that actually edit or create files are disabled. So that means you cannot create or edit content types in prod
Downloaddave commented on 22 Sep 2018:
I had deployed Strapi locally then to a Prod environment, and was confused since I didn't see the content-type-builder in the production CMS.
I'm trying to understand the deployment and update process as well...
Developer sets Strapi up locally
Creates content-types using the content-type-builder
Strapi makes updates to the file structure locally and on the local MongoDB
On production we will have to push both the code and db updates?
I understand that making changes to the content-type-builder reboots the service, and we don't want production to go down during the rebuild, but it seems like data would get really out of sync between production and development.
Aurelsicoko commented on 2 Oct 2018
You're right! The Content-Type Builder is a development plugin. His goal is to speed up the development of your project. It should not be used in production. We didn't design this plugin like for this usage.
The real pain is to migrate the development configuration to production, and vice-versa. We plan to offer a new command with the CLI called strapi migrate to easily migrate from an environment to another. I can't give you a release date though...
Any news on this strapi migrate command? It is a major thing for me and my team in order to do go on with Continuous Integration and delivery.
I hope it is not going to be same like with Wordpress that still has no native solution to solve the migrations between Prod and Stage...
Appreciate the answer. Greetings

Can API Platform be deployed in a LAMP env' on shared hosting, like Hostgator?

I currently have a reseller account through Hostgator and am wondering if API Platform can be deployed there. The documentation states "The server part of API Platform is basically a standard Symfony application, that you can also easily deploy on your own servers." but it's not clear to me whether or not the server part (e.g., /api) can be broken out of Docker and installed in a standard LAMP lamp env. It seems feasible but I'm not certain it would work like that.
Any guidance will be appreciated. Thanks in advance!
Yes it can! The Docker integration is 100% optional.
Because the content of this directory is actually just the Symfony Skeleton + the configuration for the API Platform bundle, you can just upload the content of the api/ directory on any LAMP server. Set the appropriate environment variables (for instance the RDBMS), and you’re done.

Deploy HTML only app to Heroku?

Can I use Heroku to deploy an HTML prototype?
My HTML prototypes live on Github and Heroku would be a nice way to deploy them so clients can view them.
It seems that this is unsupported, since Heroku expects a Rails/NodeJS/[insert language here] structure or it won't run.
Push rejected, no Cedar-supported app detected
Are there any tricks to circumvent this?
The best solution would be to use a buildpack designed for hosting static content.
I'd suggest the experimental heroku/heroku-buildpack-static buildpack. In brief, just set the buildpack:
heroku buildpacks:set https://github.com/heroku/heroku-buildpack-static.git
And add a static.json indicating which directory contains your static assets:
{"root":"public"}
The least effort solution is to rename your default file to index.php and redeploy. Heroku will detect it as a PHP site and use that buildpack.
Alternatively, you can follow this guide https://devcenter.heroku.com/articles/static-sites-ruby to set up a sinatra app to host it.
I've not done it before but since you mentioned using github. Why not use Github Pages to show the prototype.
You can always use an nginx buildpack to run nginx on heroku:
https://github.com/neilmiddleton/heroku-buildpack-nginx
I've used it with great success to handle a large batch of complex redirects and act as a reverse proxy to a new heroku app for an old, defunct application. Here's a simple config example that will get a static site up and running: https://gist.github.com/leklund/5877422.

how can I set up a continuous deployment with TFSBuild for MVC app?

I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.

Moving app to production mode in Symfony 2

Can someone help me to move my Symfony 2 application into production mode?
Currently, the application is running properly in /app_dev.php.
I'm googling, but I'm not finding a definite guide for deployment in Symfony 2.
Couple more things to consider:
php app/console cache:clear --env=prod --no-debug
php app/console assets:install web_directory
php app/console assetic:dump web_directory
You might also run into permission issues with the cache directory. I would actually first make sure everything works in development mode on the server before switching to production mode. And if all you get is blank screens in production mode then set debug to true. And of course know how to check your error logs.
Moving Symfony2 to production means :
access the application through : app.php/
Test dev bundles won't be loaded since there is a condition into the AppKernel.php when you use app.php. If you want to unload bundle that should be used only in dev, you can place them into the this section (in appKernel.php)
if (in_array($this->getEnvironment(), array('dev', 'test'))) {
$bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
$bundles[] = new Sensio\Bundle\DistributionBundle\SensioDistributionBundle();
$bundles[] = new Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle();
$bundles[] = new Sf2gen\Bundle\GeneratorBundle\Sf2genGeneratorBundle();
}
You also need to make some server tuning by désactivating xdebug and adding eacclerator (or someting else for caching performance)
I also advice to rename app_dev.php to disactivate dev mode
Basic configuration information can be found here:
http://symfony.com/doc/current/cookbook/configuration/web_server_configuration.html
One important spot where many people stumble is asset management. When accessing the app via the app.dev front controller (see fist link), it may be necessary to dump the assets first. Read all about it here:
http://symfony.com/doc/current/cookbook/assetic/asset_management.html#cookbook-assetic-dumping
The Symfony CookBook has now a few recipes about deployment covering:
standard linux-based web-server: How to Deploy a Symfony2 Application,
Microsoft Azure Website Cloud: Deploying to Microsoft Azure Website Cloud,
Heroku Cloud: Deploying to Heroku Cloud.
Symfony2
How to Master and Create new Environments
http://symfony.com/doc/current/cookbook/configuration/environments.html