Put It All Into Version Control Even Composer!

Posted: 2016-01-05 12:40:30

Update: September 06 2016

We stopped doing this. I do not think it is a bad idea but we ended up going with CodeDeploy on AWS. So after our CI does a Composer install and all passes, CodeDeploy will just bundle everything up as a Zip file and deploy that to the server.

Or Listen here

Another article about this written by Loran Jane Mitchell Using Composer Without GitIgnoring Vendor

I have done this for sometime with node_modules because I use to hate waiting for npm to pull down during CI builds. I could have used the CI systems cache for this but I realized once the project starts it is rare that I needed to add more libraries. And when I did it was just as easy to wipe using git rm and do them again fresh. This included my use of Bower.

But then there is Composer and PHP. The project starts and I might be pulling in libraries quite a bit but at some point we are just running composer install and never composer update. This step included rm -rf vendor which helped with the speed. And this is going great BUT has a few draw backs I will cover below.

"I have seen it too many times. Our CI goes well even our stage goes well but then git via Github gets stuck on one repo out of the many you are installing"

Speed (CI, and Deployment)

This is not HUGE but with workflow now each deployment, unless it is a quick one, we tend to just use rm -rf vendor && composer install. And it does cost us 1/2 a minute. Again not huge but nice to not have that as down time to the user. For at this point the app is not usable. And even worse as I will talk about below. And we do a lot of builds a day in the CI.

One Point of Failure VS Many

This is the big reason in my opinion. I have seen it too many times. Our CI goes well even our stage goes well but then git via Github gets stuck on one repo out of the many you are installing. This can be caused due to a misconfiguration on our part, eg using anonymous Github connections but at times I have seen it even when authenticated and am not totally sure why.

Then there are those moments, and they happen, when Github is under DDOS attack! So then it is just a day of no deployments and that is not an option really. And with this technique we have a good chance of getting a deployment in since we are just hitting one repo and not trying our luck at many.

Rollback

Then there are Rollback moments. Zero down time would be great and this is one step closer. With our releases we use Tags. So if I was to release 1.2.2 and it had a bug I could rollback to tag 1.2.1 in moments. No need to rebuild composer. Sure it saves minor amount of time but when things are down on production 1/2 a minute can feel like a life time. This does not cover all migration issues but that is not a thing we do every deployment and honestly with the migration rollback feature we have in Laravel I think that becomes an edge case that can be dealt with using Artisan and some creative coding.

"when things are down on production 1/2 a minute can feel like a life time"

Fixing Merge Conflicts

Well what happens when there is a conflict in this vendor folder? That is easy really just rm the whole thing and do what I have been doing all along composer install saving composer update only for those moments you are looking for something to really be updated and feeling lucky (and patient).