Continuous Integration vs Continuous Delivery vs Continuous Deployment

Heard about these terms ?? …….  I am sure you did 🙂

Some people says Continuous Integration and Continuous Delivery are same

Some says Continuous Delivery and Continuous Deployment are same

Some people have a myth that Continuous Delivery means all the builds are  getting automatically deployed into Live environment though automation.

Some also thinks that Continuous Integration includes automated deployment on Production/Live environment.

There are several other myths which i have heard from the people. The list not only contain the beginners but also some highly positioned professionals :O

In this fast running world where people give more value to time, human efforts and customer satisfaction,continuous Integration,  Continuous Delivery or Continuous Deployment are the vital part of any software organisation. They are an important part of DevOps life cycle.

So, what’s the difference between continuous integration vs continuous delivery vs continuous deployment. How they are linked with each other and what are the benefits to opt them …..

Lets start with Continuous Integration which is the first process among them

Continuous Integration (CI) is the process of enforcing developers to merge their code to mainstream branch or working code base as often as possible.

Continuous Integration involves triggering a build when a change gets committed to the source code repository by any developer. which includes, fetching the code from source code repository, compiling code, running automated tests and creating build out of it.

This will help to detect any integration error at earliest and gives a full visibility of the project code.

Continuous Integration creates build after running automated test for every commit. Less frequent changes means  troubleshooting will consume less time in case of any issue.

CI’s biggest advantage is reduction of risk. All the issues can be easily identified and fixed with each integration.

CI definitely makes everyone’s life easier by making software build rapidly and simple to find bugs which allow developers to fix them promptly. It will helps users to save their money, time & efforts.

Now, lets move on to the second most important part of DevOps, i.e. Continuous Delivery

Once you have fully configured the Continuous Integration process in your organisation, you should now extend the process and implement the next pillar of Software release which is Continuous Delivery

Continuous Delivery (CD) is the practice which aims to to deliver high quality software really quickly everytime.

It provides an ability to repeatedly push out enhancements and bug fixes to customers rapidly, efficiently and reliably every single time which requires minimal manual overhead as it encourages you to automate the processes.

It is recommended to keep the production and test environment similar and close together which allows a quicker automated deployment and to perform all the automated testing.

CD framework incorporates with several development technologies & techniques such as Agile, Scrum, Web/Functional/Acceptance/Unit testing, Continuous Integration and Test driven developments.

This results into building a right product quickly and there will be no delay in implementing enhancements & bug fixes and making them available to users for their feedback.

A beautiful description provided by Martin Fowler to identify when you are actually using Continuos Delivery, is shown below

Continuos Delivery basically is an extension to CI process. Once you have the build ready, CD comes into the picture and follow another set of steps of processing Automated Tests (Functional & Non-Functional) and making sure that you are always be able to put a product into production with just one click.

Continuous Delivery makes your software is always ready to go on production , however the timing of pushing it into production is purely a business decision which needs to taken after verifying every possible aspects.

Once you implement CI-CD in your organisation, you will see :

• the enhancement in team work
• reduction in cost
• able to deliver software with lower risk and negligible bugs
• able to react quickly and respond the changes more conveniently
• features gets releases more frequently
• stability and reliability
• huge reduction in manual efforts and time

Moving ahead and start the discussion on Continuous Deployment ……

There is only one difference in Continuos Delivery and Continuous Deployment ……

CD vs CD 🙂

Some people has myth that both are same …….NO ……….they are not !!

Both are following same structure but with just one difference which is huge enough to make them as two distinguish processes.

Let me explain it through one diagram …..

Easy ….. Isn’t it ??

I’m sure its easy to recognise through the diagram that the deployment to Production is also automated and triggered automatically once it is passed with all the tests in Continuous Deployment practice whereas this step is a manual step in Continuous Delivery.

Continuos Delivery means every change is always ready to deploy on Production but needs to be done manually.

The updated version of the application is automatically pushed to production through Continuous Deployment.

Only few organisations who have the belief that all the changes which gone through with the automated tests and QA are good to go on production and only those can implement Continuous Deployment in their organisation. Continuous delivery now a days is an absolute requirement of DevOps practices and being implemented in numerous organisations.

The CI-CD processes consists of following practices :

Configure a CI server and tool: A Continuous Integration server is a machine with best server configuration which can handle a high throughput and multiple tasks.

The CI tool should be correctly installed on this server with all the required packages/software in order to build the code and produce build artifacts.

** We will discuss CI tools in our upcoming articles

The CI tool will be responsible to continue checking the source code repository for any change and should trigger the build as soon it detects any change in source code repository.

This should run the full build process and create a build artifact once completed.

Configure a version control system : We have already discussed the use of Version Control System in our previous articles.

Its a most important activity for implementing SCM in your organization.

Choosing the best suitable VCS tool and implementing are vital for any project.  You should wisely configure the correct VCS in your project.

Automate the Build process : We have also discussed this feature in our earlier article Software Build Best Practices.

Automating the build process will make sure that build process is completely repeatable and consistent which will increase the productivity.

Build process should contain self-automated-testing : The build process should have a step to perform the smoke/unit testing. This will make sure that the build doesn’t break and not causing any failure.

If the test is failing then build should also fail and should trigger the notification so that developer can fix the issue before sending the build for deployment.

Once all the test cases are passed, the results should be reported quickly on the dashboard so that any defects which are found during the build can be quickly analyzed and removed promptly.

I know we can not test the other automated tests which requires a deployment on the Target environment but all other tests which doesn’t needs a deployment should be incorporated and automated in the build process itself to provide best outcome every time.

Its also not necessary to have 1 build script for all kind of builds, some build doesn’t need some sort of testing, such as UI driven testing, Backend testing, Database testing – For those kind of test cases, Build master should create separate scripts and test cases which should be called as and when required to save a lot of efforts and time.

Frequent commits and every commit should trigger a build on CI server : Its a very basic and important rule that developers should commit their changes frequently, atleast once in a day. Ideally they should commit several times a day to avoid any trouble which comes with many changes and it will not turn out into such a hard process.

This will allows developers to tell other developers about the changes they have made so that other developers can incorporate the changes or give the feedback. By following this approach, developers will be able to find out quickly  if there’s a conflict among them. This will helps all developers to track their progress.

Its a developer’s responsibility not to check-in the changes until the change is fully tested/verified by developer locally.

As soon as the changes are committed into the Version control repository, the CI tool should detect the change and triggers the build. Its the developer responsibility who checked in the changes to monitor the build carefully and fix the code or revoke the changes in case of any issue.

Smaller, less frequent changes means less time consuming troubleshooting but when you opt to work on parallel branches, it can be proven as an obstruction to Continuous Integration. Its against the general principle of frequently merging into the main code line, i.e. trunk.

Store the Build artifacts in CI server and/or with VCS : Always store the build artifacts at safe place in order to use them either for deployment or to test/check any other issue/functionality. Its recommended to use a proper tool or Version control system to keep all the build artifacts.

Or, if feasible than start using an Artifact Repository. It can be used for storing all the build artifacts at one single place.It will helps you to manage the binary artifacts and associated metadata. It also provides the audibility and tractability for all the builds and their resultant artifacts.

Build should be as quick as possible : The thumb rule of Continuous Integration is to provide rapid feedback. Builds should be fast and verified. Build which takes more time always becomes a flawed in the process, because developers starts afraid about their time and won’t commit as frequently.

Fast build will result into many builds in a day which is also helpful for developers to find out what exactly the build contains and they will be able to fix the issue really quickly.

Sending Notifications : As stated in the Build best practice article, Its a really good practice to inform all the team members who are working on the project about the build status, either in case of build failure or success.

This will also helps all the project members to get the current status of their project, they can also use the notification mails to initiate the conversation about the build failure, etc.

Automate the deployment process : Automation helps you to do repetitive tasks without using much resources in terms of both man power and hardware.

Systematising the process will ensures that your automation’s inputs & outputs are consistent every time. These are also helpful to save time, cost, efforts and provides efficient results.

Deployment process should have self-automated-testing on test environment : Basically the real part of CI gets over once you build the artefacts, however deploying the artefact to a test environment puts an extra wing to it and introduces CD in the lifecycle which helps you to find out about any issue which may occur in your test environments.

It will also helps you to quickly fix the issue and retest it on the same environment. An automated tests in deployment process will  allow you rectify any unwanted error/problem. Its an important key to achieve the best results in short span of time

Results will be visible to everyone : CI-CD is all about communication and the system state should be transparent.

Its a practice to ensure that everyone can easily see the state of the system and the changes that have been made to it

CI image credit – www.retrieverconsulting.com

I hope you now get the difference between Continuous Integration, Continuous Delivery and Continuous Deployment. As i mentioned above, these are really an important practices which needs to be implemented to get all the benefits of DevOps.

Its a long journey to understand SCM and utilising all its benefits. Hope you enjoyed our today’s article as well ……

Keep enjoying …….