Deploying to a production environment with Symfony Flex and --no-dev

Question

I have a couple of large Symfony projects, and have noticed that after updating everything to Symfony 4 (Flex), when our deployment automation runs its normal process of:

composer install --no-dev

We end up with (for example) this:

Symfony operations: 2 recipes (72fad9713126cf1479bb25a53d64d744)
  - Unconfiguring symfony/maker-bundle (>=1.0): From github.com/symfony/recipes:master
  - Unconfiguring phpunit/phpunit (>=4.7): From github.com/symfony/recipes:master

Then, as expected, this results in changes to symfony.lock and config/bundles.php, plus whatever else, depending on what was included in require-dev in composer.json.

None of this is breaking, exactly, but it is annoying to have a production deploy that no longer has a clean git status output, and can lead to confusion as to what is actually deployed.

There are various workarounds for this, for example I could just put everything in require rather than require-dev since there is no real harm in deploying that stuff, or I could omit the --no-dev part of the Composer command.

But really, what is the right practice here? It seems odd that there is no way to tell Flex to make no changes to configuration if you are just deploying a locked piece of software. Is this a feature request, or have I missed some bit of configuration here?

Answer 1

This was briefly the case on old Syfmony Flex 1 versions.

It was reported here, and fixed here.

It this happens to you, it means you have a very old installation on your hands, and you should do your best to at least update Symfony Flex to a more current version (Symfony Flex 1 does not even work anymore, so switching to Flex 2 if possible would be the only way, or simply remove Flex in production).

Answer 2

If you deploy to prod from your master branch, you can setup a deploy branch instead. And in that branch you can prevent certain files from being merged in. See this post for more detail. This creates a situation in which you have a master branch, a version branch (example: 3.21.2) and you're having devs checkout master, work on it, then merge their changes into the version branch. From there you pick and choose what gets deployed to prod. (There will be a small balancing act here. You'll want to merge all dev changes into master until it matches your version branch and make sure master matches the version after you've deployed. This adds a bit of work and you have to keep an eye on it. etc.)

Another option is to separate your git repository from your deployment directory. In this example, a git directory is created in /var/repo/site.git and the deploy directory is /var/www/domain.com and a post-receive git hook is used to automatically update the www directory after a push is received to the repo/site directory. You obviously run composer, npm, gulp, whathaveyou in the www directory and the git directory is left as is.

Without getting into commercial options such as continuous deployment apps, you can write a deployment script. There are a lot of ways to write a shell script that takes one directory and copies it over, runs composer, runs npm, etc. all in one command -- separating your git from your deploy directories. Here's a simple one that makes use of the current datetime to name a directory then symlinking it to the deployment directory.