January 22, 2016
If you know me, you know I almost always deploy to AWS. One of the AWS products I use frequently is Elastic Beanstalk. Most of the tutorials out there, that explain how to deploy a PHP/Composer application to Elastic Beanstalk, will say to define a hook that usually contains the following:
commands: 01_update_composer: command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update
It's commonly known that the AMIs in the Elastic Beanstalk feature roll with an almost-always outdated version of Composer (i.e. unsupported composer.json syntax). So for good measure, the tutorials will give you this step, and everything should just work™.
That's until a breaking change is introduced into Composer and reported by a bunch of end users.
What happened was that Composer was no longer including the environment variable COMPOSER_HOME, so when you go to deploy your application with eb deploy, it'll fail and return to a previous state—leaving your application unchanged. Not the end of the world, but what happens when AWS tries to add a new instance to the load balancer? It fails, because your hook is downloading the newest version of Composer (which may happen to break). Now your users see a potentially half deployed application—fantastic.
How does one recover from such an event?
Firstly, stop trusting your package sources and lock your packages (package managers included) down to a minor version. Using the newest composer all the time is just like using the dev branch of any project, you can do so locally, but not in a production environment.
Secondly, if you're using a service like Elastic Beanstalk and they're providing an outdated version, then find the tag you need and install composer up to that tag:
commands: 01_update_composer: command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update 1.0.0-alpha11
FYI, yes this happened to me. No, my process isn't perfect, but every failure is an attempt at learning, and now my deployment process will remain unaffected by Composer qualms.