Current Articles | RSS Feed RSS Feed

Continuous Delivery vs Continuous Deployment vs Continuous Integration - Wait huh?

Posted by Michael Chletsos on Thu, Nov 29, 2012

We have been writing a lot about Continuous Delivery and Continuous Integration and have discussed Continuous Deployment in our blog series.  If you are like most people these buzzwords are confusing and often misused.  I am going to try to dispel some of the confusion surrounding these processes and how they can all work together to provide a kickass environment that Managers, Developers and Customers love alike.

Continuous Integration

Continuous Integration is the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes.  The idea here is to test your code as often as possible to catch issues early.  Most of the work is done by automated tests, and this technique requires a unit test framework.  Typically there is a build server performing these tests, so developers can continue working while tests are being performed.

Continuous Delivery

Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship.  This could be UAT or Staging or could be Production.  But the idea is you are delivering code to a user base, whether it be QA or customers for continual review and inspection.  This is similar to Continuous Integration, but it can feed business logic tests.  Unit tests cannot catch all business logic, particularly design issues, so this stage or process can be used for these needs.   You may also be delivering code for Code Review.   Code may be batched for release or not after the UAT or QA is done.  The basis of Continuous Delivery is small batches of work continually fed to the next step will be consumed more easily and find more issues early on.  This system is easier for the developer because issues are presented to the developer before the task has left their memory.

Continuous Deployment

Continuous Deployment is the deployment or release of code to Production as soon as it is ready.  There is no large batching in Staging nor long UAT process that is directly before Production.  Any testing is done prior to merging to the Mainline branch and is performed on Production-like environments, see Integration blog article for more information.  The Production branch is always stable and ready to be deployed by an automated process.  The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button).  After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively.  Some of these metrics may include revenue, user sign-up, response time or traffic, preferably these metrics are graphed for easy consumption.  Continuous Deployment requires Continuous Integration and Continuous Delivery - otherwise, you are just cowboy coding and you will get errors in the release.

Once you have moved to a Continuous Deployment process, you will have to have several pieces of automation in place.  You must automate your Continuous Integration Build Server and Continuous Delivery to Staging, as well as have the ability to automatically deploy to Production.  


cd process diagram resized 600

In the ideal workflow, the entire process could be automated from start to finish:  Developer checks in code to development branch, Continuous Integration Server picks up the change, performs Unit Tests, votes on the Merge to Staging environment based on test results, if successful deploys it to Staging Environment, QA tests the Environment, if passed, they vote to move to Production, Continuous Integration server picks this up again and determines if it is ok to merge into Production, if successful, it will deploy to Production environment.  This process varies slightly based on needs, requirements and approaches.  

Continuous Deployment relies on small changes which are constantly tested and that are deployed and released to Production immediately upon verification.  The ownership of the code from development to release must be controlled by the developer and must be free flowing.  The automation of steps allows this process to be implemented and executed without cumbersome workflows. Also, check out our Continuous Delivery page to see how the Assembla product helps you deliver quicker.

Tags: , , ,


Finally, some one has words that makes sense. I could not tell the difference before, thanx

posted @ Friday, November 30, 2012 2:59 AM by israel

Looking at your ideal workflow i am wondering what you mean by: "Continuous Integration server picks this up again and determines if it is ok to merge into Production" I thought that after QA says "pass" an artifact/artfiacts QA team was testing against could be simply deployed to production. I do not get what kind of CI build will be performed on "after-UAT/Staging Environment" CI Server?

posted @ Friday, December 28, 2012 12:03 PM by jmilkiewicz

The final check on the CI server before going to Production is optional - however, it is there to ensure that the merge process was successful and that there were no issues introduced between the previous CI process and the merge to Mainline. It is a final verification that everything is as you expect before moving forward.

posted @ Friday, December 28, 2012 12:16 PM by Michael Chletsos

Thx for the response. I have been using CI for a long time but continous delivery/deployment are quite new to me. 
I am always confused reading blog entries/articles/product brochures on these since each author presents them in a different way, with different workflows/tools, but what's the worst - using the same vocabulary being inconsistent among authors :(.  
I am always looking for some best practices/ patterns i could adopt/extend for my own needs but continous delivery/deployment landscape seems really unstandardized to me... 
So regarding my initial question: Is the 2nd CI build about merging developer branch with mainline and checking if merge was "successful" (by successful i mean not only that both developer branch and mainline could be merged but that the result of merge is "valid") ? What do you exactly mean by: "and that there were no issues introduced between the previous CI process and the merge to Mainline"? By issues do you mean any modifications to mainline which happened in the meantime ( after the first CI server build and before merge to mainline ) which could be successfully merged ( from SCM point of view) with developer modifications but would result in invalid/broken version ? 
Can you provide me with any example where this kind of process/workflow was employed?  
BTW, i am wondering what would happen if 2 developers (dev A and dev B) at the same time make commits to their own developer branches (dev A to branchA and dev B to branchB) . It could happen that both branches would be build independently and if successful, both versions (version A built from branch A and B from branch B) of a single application would be deployed to staging (assuming we have more than one staging/UAT environment) . Then QA team will do some manual testing. If both versions are fine, testers mark them independently as passed, so they can be merged with mainline and deployed to prod. The problem is that the second merge (being successful merge from SCM point of view) would produce a version of application (ewault of merge of branchA and branchB) which has never been deployed/checked on any environment - So although, merge was successful, the version built from both of branches: branchA and branchB, can be broken.

posted @ Monday, December 31, 2012 9:21 AM by jmilkiewicz

Hi again- 
What do you exactly mean by: "and that there were no issues introduced between the previous CI process and the merge to Mainline"? 
I mean that sometimes merges are not perfect and sometimes people do things outside of processes, this is just a double-check that everything is as expected 99.999% of the time, it should be the same as the previous CI process if you follow the procedures, hence why I say it is not necessary. 
We currently use this process at Assembla. 
Each developer branch is deployed to their own QA/UAT process - upon merging to Mainline, they can be deployed to a batched QA/UAT area, this would not conflict if multiple devs commit because it will be both of their work going forward. This is another use of the 2nd CI process - it all depends on your workflow. One way is to prevent 2 merges going forward at a time, this is a minor inconvenience - another. 
Feel free to email me anytime to discuss in greater detail than the comments can here:

posted @ Monday, December 31, 2012 10:12 AM by Michael Chletsos

I will contact you directly next year :). 
BTW what kind of SCM do you use ? Looking at tags you are using SVN, aren't you ?

posted @ Monday, December 31, 2012 11:53 AM by jmilkiewicz

looking forward to it - we can get much more into the nitty gritty then . . .  
We use git - tags are not just for svn . . . and a tag is really nothing more than a branch in git - well sort of, or is it because I call it Mainline - well that is a concept . . . 
But yes, git - it lends itself to more branching and merging - being the dvcs that it is.

posted @ Monday, December 31, 2012 12:01 PM by Michael Chletsos

Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: