mattwillsher · September 3, 2012 16:11 · Sep 3, 2012 · Sep 3, 2012 · Sep 3, 2012 · Sep 3, 2012
diff --git a/gistfile1.md b/gistfile1.md
@@ -25,7 +25,7 @@ Developing an Application
 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.
 
 Why?
-To get the latest version of the code... why we we do this? For specific bug fixes or features?
+To get the latest version of the code... why we we do this? For specific bug fixes or new features?
 
 Deploying an Application
 -------------------------

diff --git a/gistfile1.md b/gistfile1.md
@@ -23,6 +23,7 @@ Developing an Application
 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 update and commit the 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.
+
 Why?
 To get the latest version of the code... why we we do this? For specific bug fixes or features?
 

diff --git a/gistfile1.md b/gistfile1.md
@@ -13,14 +13,18 @@ Creating an Application
 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.
+
+Why?
+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.
+3. If all is well, I update and commit the 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.
+Why?
+To get the latest version of the code... why we we do this? For specific bug fixes or features?
 
 Deploying an Application
 -------------------------
@@ -29,4 +33,7 @@ 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.
+4. ```composer update``` is never run on the production environment as it would install versions of vendor code that we have not tested.
+
+Why? 
+The versions deployed into production are the same as those we have tested against.
diff --git a/gistfile1.md b/gistfile1.md
@@ -0,0 +1,32 @@
+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.