Composer workflow with Git

gistfile1.md

Composer Workflow

Example of why composer.lock should be version controlled and workflow of how it can be used.

The reason we put ranges in composer.json is so that we can check for updates in our development environment and test our source code works with it BEFORE it goes into production.

The reason we have specific versions of vendors in composer.lock is so that we can version it and install the application into production environments with the versions we have tested while in development. Because of this we never run composer update on a production environment.

Creating an Application

1. As a developer I create the basics of a new application and install my vendors using composer install
2. I commit my new application, including composer.json and composer.lock
3. Someone else in my team starts work on the system, and checks out my code
4. They run composer install which installs vendors from the composer.lock file
5. Now we both have the same versions whilst we work on our code reducing inconsistencies in our codebases which makes debugging easier.

Developing an Application

1. I'm working on my application and commit my changes. Before I push it to git, I run composer update to see if new vendors are available. Some are, and they get updated.
2. I test the areas of my app that would be affected by the updated vendors. I also make any changes necessary to make sure the code that relies on the updated vendors works.
3. If all is well I commit the new composer.lock file and push all my changes to git.
4. My colleagues working on the app pull the new code and composer.lock from git. They run composer and get the same versions of the vendors we use in the application.

Deploying an Application

When I deploy my app I:

1. Checkout the code on the production environment
2. Add any configuration that's needed
3. Run any build scripts and also composer install which will install the vendors from the specific versions in the composer.lock file that the developers have already tested.
4. composer update is never run on the production environment as it would install versions of vendor code that we have not tested.