Continuous Integration vs Continuous Delivery vs Continuous Deployment 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 ……

1. 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

2. In this fast running worldwherepeoplegive morevalueto time, human effortsandcustomer
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
sourcecoderepositorybyany developer.which includes, fetching the codefromsourcecode
repository, compiling code, running automated tests and creating build out of it.
This will helpto detect any integration erroratearliest andgives a full visibility ofthe project
code.

3. 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’slifeeasierby making software build rapidly andsimple 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

4. 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 !!
Bothare following same structurebut with just onedifferencewhich is hugeenoughto make
them as two distinguish processes.
Let me explain it through one diagram …..

5. 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.

6. 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
ContinuousDeployment in their organisation.Continuousdelivery 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 havealready discussedthe use of VersionControl
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.

7. 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 onCI server : Its averybasic
and important rule that developers should commit their changes frequently, at least 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 allow 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 help all developers to track their progress.
It's 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 frequentchanges mean lesstime-consuming troubleshooting butwhen youopt
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

8. always becomesa flawed in the process,becausedevelopersstartafraidabouttheir 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, It's a really good practice
to informall the team members who areworking onthe projectabout the build status, either
in case of build failure or success.
This will also help 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.
Systematizing 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.
It's 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 practice which
needs to be implemented to get all the benefits of DevOps.
It's a long journey to understand SCM and utilizing all its benefits. Hope you enjoyed our
today’s article as well ……
Keep enjoying …….