How to deploy a Symfony program

Deploying Symfony can be a complex and varied task, depending on your application's setup and needs. This article is not a step-by-step guide, but rather a list of common requirements and recommendations when deploying.

Symfony Deployment Basics ¶

Typical steps that occur when deploying Symfony include:

Put your Upload code to the production server;
Install third-party dependencies (usually done through Composer, and can be done before uploading the program);
Run database migration (migration) or similar tasks to update " "Changed" data structure;
Clear (optionally, warm up) your cache.

The deployment process also includes other tasks, such as:

Tag a specific version of the code as a release in your version library;
Create a staging area to build your "offline" offline updated setup;
Run any available tests to ensure code and/or server stability;
Fromweb/ directory removes any unnecessary files to keep the production environment clean;
Clear external cache systems (such as Memcached or Redis).

How to deploy Symfony program ¶

There are several ways to deploy Symfony program. Start with some basic deployment strategies and go from there.

Basic file transfer ¶

The most basic way to deploy a program is to manually copy files through FTP/SCP (or similar methods). The disadvantage is that, for example, during the upgrade process, you lack control over the system. This method also requires you to perform some manual steps after the file transfer (see Common post-deployment tasks).

Use version control ¶

If you use version control (such as Git or SVN), you can directly make the live installation into your repository a copy. When you're ready to upgrade, it's as simple as pulling the latest update from your version control system.

This makes updating your files easier, but you still need to consider performing additional steps manually (see Common post-deployment tasks).

Use platform services ¶

Rarely used Users who have related needs, please refer to the original text of Symfony official website. In addition, modern cloud platforms, such as Microsoft Azure, can support Symfony3 in one step.

Special deployment steps vary widely between service providers, so find the service of your choice from these stand-alone articles:

Using build scripts and other tools ¶

There are several tools that can help ease the pain of deployment. Some of them are almost tailor-made for Symfony's needs:

Capistrano Cooperates with Symfony plugin
Capistrano is a remote server automation and deployment tool written in Ruby. Symfony plugin is a plugin that simplifies Symfony related tasks, inspired by Capifony (it only works with Capistrano 2)
sf2debpkg
Help you build a native Debian package for the Symfony project.
Magallanes
This "Capistrano-like" deployment tool is built in PHP, making it easier for PHP developers to extend their needs.
Fabric
This Python-based class library provides a basic suite for "executing local or remote command lines and uploading and downloading files".
Deployer
This is another Capistrano rewritten from native PHP, with some features specifically provided for Symfony.
Bundles
There are some bundles that have added deployment capabilities that can be used directly in your Symfony console.
Basic Script
You can of course use the command line, Ant or any other build tool to script the deployment of your project.

Common post-deployment tasks ¶

After deploying your real source code, there are some common things you need to do:

A) Requirements Check ¶

Run the following command to check if the server meets the requirements:

1	$ php bin/symfony_requirements

B) Configure the app/config/parameters.yml file ¶

This file should not be deployed, but will be deployed by Symfony An automated tool is provided to manage.

C) Install/update vendors ¶

Your vendors (three-party packages) can be updated before uploading source code (such as updating vendor/ directory, and then upload the source code) or complete the update on the server. Either way, just update vendors as usual:

1	$ composer install --no-dev --optimize-autoloader

##By building a "class map" class map,

--optimize-autoloader Flags greatly improve Composer's autoloading performance. --no-dev Flag ensures that development environment packages are not installed into the production environment.

If you get a "class not found" error at this step, you may need to run

export SYMFONY_ENV=prod## before executing the preceding command. # So that the post-install-cmd script runs in the prod environment.

D) Clear Symfony Cache

Make sure you clear (and warm-up) your Symfony cache.

$  php bin/console cache:clear --env=prod --no-debug

E) Strip Assetic resources

If you use Assetic, you need to strip assets:

F) Other content! ¶

Run database migration
Clear APC cache
Run assets:install (Already in composer install The process has been managed)
Add/edit CRON task
Publish assets resources to CDN
...

Program Life Cycle: Continuous Integration, Quality Assurance, etc. ¶

While this article covers the technical details of the deployment process, the complete life cycle of code from development to production may require more Steps (think staging deployment, QA [Quality Assurance/Quality Assurance], running tests, etc.)

staging, testing, QA, continuous integration, database migration and backward compatibility in case of failure, All are strongly recommended. There are a variety of simple or complex tools, one of which will make the process of deploying to meet the needs of your environment easier (or more sophisticated).

Don’t forget that the deployment process also involves updating dependencies (usually through Composer), migrating databases, clearing caches, and other potential matters, such as publishing resources to CDN (refer to Common post-deployment tasks ).

← Database and Doctrine ORM

How to send email →

submit

php.cn

$  php bin/console assetic:dump --env=prod --no-debug