发布于 2015-08-27 16:42:24 | 174 次阅读 | 评论: 0 | 来源: 网络整理
注解
Deploying can be a complex and varied task depending on the setup and the requirements of your application. This article is not a step-by-step guide, but is a general list of the most common requirements and ideas for deployment.
The typical steps taken while deploying a Symfony application include:
A deployment may also include other tasks, such as:
web/ directory to keep your
production environment clean;There are several ways you can deploy a Symfony application. Start with a few basic deployment strategies and build up from there.
The most basic way of deploying an application is copying the files manually via ftp/scp (or similar method). This has its disadvantages as you lack control over the system as the upgrade progresses. This method also requires you to take some manual steps after transferring the files (see Common Post-Deployment Tasks)
If you’re using source control (e.g. Git or SVN), you can simplify by having your live installation also be a copy of your repository. When you’re ready to upgrade it is as simple as fetching the latest updates from your source control system.
This makes updating your files easier, but you still need to worry about manually taking other steps (see Common Post-Deployment Tasks).
There are also tools to help ease the pain of deployment. Some of them have been specifically tailored to the requirements of Symfony.
The Symfony Cookbook includes detailed articles for some of the most well-known Platform as a Service (PaaS) providers:
After deploying your actual source code, there are a number of common things you’ll need to do:
app/config/parameters.yml File¶This file should not be deployed, but managed through the automatic utilities provided by Symfony.
Your vendors can be updated before transferring your source code (i.e.
update the vendor/ directory, then transfer that with your source
code) or afterwards on the server. Either way, just update your vendors
as you normally do:
$ composer install --no-dev --optimize-autoloader
小技巧
The --optimize-autoloader flag improves Composer’s autoloader performance
significantly by building a “class map”. The --no-dev flag ensures that
development packages are not installed in the production environment.
警告
If you get a “class not found” error during this step, you may need to
run export SYMFONY_ENV=prod before running this command so that
the post-install-cmd scripts run in the prod environment.
Make sure you clear (and warm-up) your Symfony cache:
$ php app/console cache:clear --env=prod --no-debug
If you’re using Assetic, you’ll also want to dump your assets:
$ php app/console assetic:dump --env=prod --no-debug
There may be lots of other things that you need to do, depending on your setup:
assets:install (already taken care of in composer install)While this entry covers the technical details of deploying, the full lifecycle of taking code from development up to production may have a lot more steps (think deploying to staging, QA (Quality Assurance), running tests, etc).
The use of staging, testing, QA, continuous integration, database migrations and the capability to roll back in case of failure are all strongly advised. There are simple and more complex tools and one can make the deployment as easy (or sophisticated) as your environment requires.
Don’t forget that deploying your application also involves updating any dependency (typically via Composer), migrating your database, clearing your cache and other potential things like pushing assets to a CDN (see Common Post-Deployment Tasks).