Continuous Integration and Continuous Delivery/Deployment



As you can see in above image what constitutes continuous integration and what in continuous delivery/deployment. The only difference between continuous delivery and continuous deployment is continuous delivery requires manual action (mostly approval from management) before it can be deployed on production system, where continuous deployment is a process in which code changes (commit/merge to production branch) makes it eligible for production deployment, after first 3 phases are success.  Here we will be describing practice to follow for CI and CD


CI –

It constitutes of your source code committed to some repository and automated build of that code.

It is highly recommended for developer to frequently commit code to the repository to avoid conflicts and find issue/bug up front. Most of time it is master or dev branch of your repository where developer commits code.

Whenever there is a commit in the branch, it need to be built, run unit and integration tests and on any issue respective dev (or dev team) should be informed of build failure.

CD –

CD contains all four steps. It start with commit/merge, but this time it could be staging or production branch. Staging branch if we are following continuous delivery and production branch if we are following continuous deployment. (Note – Even if we are following continuous delivery after approval/manual action, it need to moved to production).

Testing phase involves QA testing, Load testing, Security/Penetration testing, Acceptance testing etc. Of course you need to deploy application(s) before these can be tested, but that you do in staging environment/infrastructure. Where deploy in above image refer to production deployment only.

As best practice keep atleast 3 branches (or more as per your environments)  – dev/master, stage/uat, production. By following this you can automate different stages working on different branches.


Example –

Code committed in master/dev branch – build code, run unit test cases, perform automated integration checks

Code merged from dev branch to stage branch – above steps plus push build to stage environment, perform automated functionality tests, perform load and security test. Inform stake holder about new build available to verify.  Most of things in this stage are manual or needs manual intervention, which makes continuous deployment tough.

Code merged from stage to production branch – build code, run unit test, integration tests, normally only security tests(if code moved from stage to production) or any test which differs your staging and production environment. Move build to production environment, inform stakeholders/customers.

Tools like AWS Code Pipeline can be useful doing that if you are on AWS cloud.





Continuous integration and Continuous Delivery is must. Continuous Deployment seems less possible but it can be used in some type of applications. As we know, now days IT industry focusing on DevOps, these process will surely help you to be competitive in market.

Below are some categorization of tools/process which fall in each category –

Source (Code) – Git, SVN etc

Build – Jenkins, Maven, ANT, Shell Scripts, Graddle,Unit and integration testing frameworks

Test – Selenium, JMeter, SoapUI etc

Deploy –  AWS Beanstalk, AWS CodeDeploy


Leave a Reply

Your email address will not be published. Required fields are marked *

9 − eight =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>