CODEWITHSUNDEEP
gitdeploymentcomposer-php
sudoyum
sudoyum

Reputation: 156

`composer install` for production deployments

We have a mission critical application that is deployed to ~200 EC2 instances using Chef

Our vendor directory is currently GIT ignored, but we have committed important dependencies into GIT elsewhere and are autoloading them. Our plan is to migrate to the more conventional approach of installing everything via Composer within /vendor and using the composer autoloader.

My question is: When we release / bulk-deploy (200+ servers simultaneously), the code is pulled from GIT into a new release directory on the server and thus we will need to execute our composer install. Are there any techniques for "increasing" reliability of composer install? or is there actually nothing to worry about. Given our number of servers, even a 1% failure rate means a client has an outage.

We have another application that triggers composer install on each deployment and at least for 24 hours we couldn't deploy because one of the dependencies was "down" or moved. What are some ways to circumvent this issue, while still avoiding committing our dependencies into our main GIT?

Thanks!

Upvotes: 1

Views: 2888

Answers (3)

Chris Heney
Chris Heney

Reputation: 92

Best practices are straightforward. Create a build script to push to version-tagged release branches.

I know we aren't compiling code in C here, but understanding the steps of creating something that is production-ready is important.

It doesn't matter what package manager you're using, NPM, composer, bower, etc ... It's important to go through your resource/asset manifest and create a "compiled" (minified/combined/etc) version.

NPM, in contrast, solves this with gulp and gulp tasks. Whereas composer as run-scripts ... I am also searching for the process for this for WordPress Plugin deployment as we do not have access to the production servers which we are deploying.

Upvotes: 0

sudoyum
sudoyum

Reputation: 156

We implemented Jenkins to clone our GIT, run composer install for production, execute a few shell scripts to help package things up, and we generate a .tar.gz and publish the file into a builds bucket on AWS S3 (file names based on branch being built). We adjusted our deployment system to fetch from the S3 bucket (which has very restricted permissions to protect access to the code)

Upvotes: 1

Jens A. Koch
Jens A. Koch

Reputation: 41776

Are there any techniques for "increasing" reliability of composer install?

What are some ways to circumvent this issue, while still avoiding committing our dependencies into our main GIT?

My suggestions:

  • do not run Composer on production
  • build and package your application for deployment
  • running composer install and fetching the dependencies is a build step
  • the final product of the build toolchain is a packaged application including vendor dependencies and autoloading - ready for deployment
  • then deploy your software v1.2.3 to x number of instances

(Sidenote: the Composer Autoloader generates relocatable files. The path is dynamic and not tied to a specific directory. This allows to unzip a packaged application with vendor dependencies fetched and autoloading generated into any folder.)

Upvotes: 1

Related Questions