Continuous Deployment - How to Composer Install instead of on production server - Pros/Cons

So today I've been running into a huge issue that I haven't encountered before. This issue basically took down my site for many hours, naturally, I want to remedy this for the future and do things better.

The issue was that Composer was/is hanging on the "Updating dependencies" step, forever!! Like, literally 20+ minutes. Which then causes Codedeploy to timeout, and the build tool cannot catch this before as it's not a code error. Very shitty situation.

This is the whole composer.json in case you think "wtf, 20+ minutes"

"require": {
    "php": ">=7.0.0",
    "slim/slim": "^3.10",
    "slim/twig-view": "^2.4",
    "illuminate/database": "^5.6",
    "vlucas/phpdotenv": "^2.4",
    "symfony/console": "^4.1",
    "league/container": "^2.4",
    "predis/predis": "^1.1",
    "slim/flash": "^0.4.0",
    "robmorgan/phinx": "^0.10.5",
    "illuminate/pagination": "^5.6",
    "vlucas/valitron": "^1.4",
    "league/flysystem-aws-s3-v3": "^1.0",
    "odan/slim-csrf": "^1.0",
    "intervention/image": "^2.4",
    "illuminate/events": "^5.6",
    "piwik/device-detector": "^3.11",
    "nochso/html-compress-twig": "^2.0"

I am still unsure what causes this, as I said, I have never had this issue before.

But this got me thinking, wouldn't it be better if I do the composer install -on --no-dev --prefer-dist -d /var/www/ during the continuous deployment and then have it ready once it hits the production server.

instead of running this on production, during deployment.

Can you guys tell me if that's a good ay, and maybe give me some tips how I can achieve this / what tools for continuous deployment I could use that support this (and codedeploy).

Thanks! :)

D9705996

7 years ago

Best Answer

Level 51

It's a bad idea to run any lengthy operation on you production code during a deploy.

There are numerous options and approaches but the one I have found most reliable is to use separate folders for each deploy (I use my git commit reference as folder name), run all the commands like composer update, npm install, etc in this folder and then if they all succeed I point the symlink for /var/www/html to this folder and run any migrations.

The symlink command takes milliseconds to complete so very little if any downtime (depends on migration time)

If things blow up you can just rollback db and reset the symlink to the last commit reference.

I based my approach on this gitlab blog - https://docs.gitlab.com/ee/ci/examples/laravel_with_gitlab_and_envoy/

1 like

madsem

7 years ago

Level 4

Thanks @D9705996

That actually makes a lot of sense and I will try this strategy on other projects. Because of the way AWS CodeDeploy works this is not really possible there.

Meanwhile i figured out what the problem was, it has something to do with IPV6 config, but not sure if on my end or packagist's end.

The solution was: https://getcomposer.org/doc/articles/troubleshooting.md#operation-timed-out-ipv6-issues-

I had to run sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf" to give IPV4 priority and then composer install completed in seconds again, instead of hours / time outs.

But my final solution for this never to happen again, on this project, was to remove the composer install from my deployment script and instead use Codeship as CI tool. There I created a deployment flow consisting of two steps: run composer install and then upload to s3 which triggers the CodeDeploy application that deploys to my auto scaling group.

Now if composer fails for any reason (or any other long running operation) the CI deployment will fail, and it never reaches production. On production I only run migrations and file permissions, and that is it.

Please or to participate in this conversation.