CI/CD: Introduction to Continuous Integration,
Continuous Delivery and Deployment
What is CI/CD?
CI and CD stand for continuous integration and continuous delivery/continuous deployment. In
very simple terms, CI is a modern software development practice in which incremental code
changes are made frequently and reliably.
Automated build and test steps triggered by CI ensure that code changes being merged into the
repository are reliable. The code is then delivered quickly and seamlessly as a part of the CD
process. In the software world, the CI/CD pipeline refers to the automation that enables
incremental code changes from developers’ desktops to be delivered quickly and reliably to
production.
Continuous Integration
Continuous integration is a DevOps software development practice where
developers regularly merge their code changes into a central repository, after
which automated builds and tests are run.
The key goals of continuous integration are to find and address bugs quicker,
improve software quality, and reduce the time it takes to validate and release
new software updates.
Why is Continuous Integration Needed?
In the past, developers on a team might work in isolation for an extended
period of time and only merge their changes to the master branch once their
work was completed. This made merging code changes difficult and timeconsuming, and also resulted in bugs accumulating for a long time without
correction. These factors made it harder to deliver updates to customers quickly.
How does Continuous Integration Work?
With continuous integration, developers frequently commit to a shared
repository using a version control system such as Git. Prior to each commit,
developers may choose to run local unit tests on their code as an extra
verification layer before integrating. A continuous integration service
automatically builds and runs unit tests on the new code changes to
immediately surface any errors.
How does Continuous Integration Work?
Continuous Integration Benefits
Improve Developer Productivity: Continuous integration helps your
team be more productive by freeing developers from manual tasks
and encouraging behaviors that help reduce the number of errors
and bugs released to customers.
Continuous Integration Benefits
Find and Address Bugs Quicker: With more frequent testing, your team
can discover and address bugs earlier before they grow into larger problems
later.
Deliver Updates Faster: Continuous integration helps your team deliver
updates to their customers faster and more frequently.
Continuous Delivery
Continuous delivery is a software development practice where code changes
are automatically prepared for a release to production. A pillar of modern
application development, continuous delivery expands upon continuous
integration by deploying all code changes to a testing environment and/or a
production environment after the build stage. When properly implemented,
developers will always have a deployment-ready build artifact that has passed
through a standardized test process.
Continuous Delivery
Continuous delivery lets developers automate testing beyond just unit tests so they
can verify application updates across multiple dimensions before deploying to
customers. These tests may include UI testing, load testing, integration testing, API
reliability testing, etc.
Once the code is integrated, build and passes the automated tests, the built is pushed
to the mock server. This enables the developer to check the application on the
production-like environment and confidently upload it on the actual production
environment — ensuring that the software will work well when it reaches to the
customer.
Continuous Delivery
The main goal of continuous delivery is to make the application deployment
seamless, reduce risk and ensure the application will work great in the
production environment.
With CD, the application is always ready to deploy and there is no last-minute
anxiety or urgency. Even the team can be confident about their codebase and
can concentrate on their daily development tasks.
Continuous Delivery
Benefits of Continuous Delivery
Faster Releases: Automating the release process reduces the time and effort required to
deploy changes.
Reduced Risk: Deploying smaller changes more frequently reduces the risk of
introducing major bugs.
Consistent Environments: Using identical environments from development to
production prevents environment-specific bugs.
Improved Collaboration: Developers, testers, and operations teams collaborate more
effectively.
Continuous Deployment
While Continuous Delivery makes the codebase ready for the deployment, Continuous
Deployment releases it directly to the production server.
Continuous deployment is a practice for application deployment wherein any code commit
passing the automated testing is automatically released to the production server and made
available to the users.
This process of deployment is fully automated without any manual intervention — and the
build components that don’t pass the production pipeline are prevented from deploying on the
server.
Continuous Deployment
This kind of automatic deployment works great to ship the new components
and features of the application and bug fixes quickly to the customers. Users’
feedback is quick as customers stay in the loop with every update and even the
team experiences peace of mind as there is no pressure of release date. Thus,
ultimately developers can focus more on developing the application and see
their work go live.
Continuous Deployment
Benefits of Continuous Deployment
Faster Delivery: New features and bug fixes are available to users immediately.
Increased Productivity: Developers focus on coding rather than manual
deployment tasks.
Reduced Risk: Deploying small, frequent changes minimizes the impact of bugs.
Improved Customer Satisfaction: Faster delivery of new features enhances the
user experience.
Metrics to track CICD practices
The primary goal of any DevOps practice revolve around three aspects: Time, Quality and
Speed. Based on the aforementioned factors, the metrics can be grouped as follows:
 Time-based metrics
 Quality metrics
 Automation metrics
Time-based metrics
 One of the main objectives of DevOps is to save time and ship code as fast as possible. Hence,
evaluating the performance of a CI/CD initiative predominantly revolves around measuring the
time taken for each of the activities involved. Given below is a list of the common time-based
metrics that organizations measure:
•
Time to market (TTM)
• Defect resolution time
• “Code freeze-to-delivery” time
• Deployment time
Time to Market(TTM)
 This defines the duration between the ideation of a feature and the “go-live” of the same. Your CI/CD
efforts should significantly shrink the time taken to launch a feature to your customers. While
traditional software delivery takes 3-6 months for every internal software release, continuous
delivery can foster multiple releases weekly or daily.
It is therefore essential to keep a close watch on the time taken to release a feature to the customer
and if the continuous integration and continuous delivery principles have helped you shrink TTM.
 If there’s no improvement, the reason could be the technologies you have employed, the workload
of the developers, the complexity of the feature. You should retrospect to see where the issue is and
fix it to increase the speed of your CI/CD pipeline.
Defect resolution time
 Defect resolution time or the lifetime of a defect defines the time taken to
resolve an issue, raised after the code has been delivered or deployed. The time
taken to resolve a defect can significantly impact your customer churn rate. The
longer it takes to resolve an issue, the higher your churn rate will be. So, if the
defect resolution loop is lengthy despite implementing your DevOps practices,
there must be some process gaps that you need to identify and fix immediately.
Defect resolution time
The churn rate in CI/CD refers to the frequency of changes made to
code, deployments, or tests over a given period. High churn rates
can indicate instability in the development process, frequent rework,
or inefficiencies in the pipeline. Monitoring churn rate helps teams
identify areas for improvement and enhance software quality and
stability.
Defect resolution time
Code Churn Rate: Measures how often code is rewritten or
modified after being committed.
Deployment Churn Rate: Tracks the frequency of deployments
rolled back or modified shortly after release.
Test Churn Rate: Assesses how frequently automated tests are
modified due to failures or inefficiencies.
“Code freeze-to-delivery” time
 This defines the duration between the code freeze in the team and
the delivery of the code. Continuous integration shortens this time
frame. If it does not, you need to understand why and fine-tune your
practices to achieve the desired result.
Deployment time
 Since CI/CD practices involve a lot of automation, the code deployment should
happen at the click of a button. If your team takes an hour or so for deployment,
the process is at the peak of inefficiency. Tracking this metric helps you increase
the frequency of deployment by eliminating the bottlenecks that hamper the
speed of the pipeline.
Quality Metrics
 Tracking quality metrics is invariably the most important aspect of DevOps. You might be
shipping your code at your own pace. However, the last thing you would want to do is to
compromise on the quality of your code. It is therefore pivotal to keep a check on how you are
doing on quality. The quality metrics that organizations track include, but are not limited to:
• Test pass rate
• Number of bugs
• Defect escape rate
Test pass rate
The test pass rate gives you a clear picture of the quality of your product, based
on the percentage of passed test cases. It can be calculated by dividing the
number of passed test cases with the total number of executed test cases. This
metric also helps you understand how well your automated tests work and how
often code changes are causing your tests to break. Continuous integration and
continuous delivery cannot be done without automated testing.
Number of bugs
This metric is crucial for your continuous deployment efforts because shipping
a buggy code faster will only deliver more bugs to your customers, causing
intricate problems later on. Hence, it is essential to regularly monitor the
number of bugs and scrutinize the root cause in case of a spike. With a buggy
code in the system, none of the DevOps initiatives will yield the results that it
should.
Defect escape rate
The defect escape rate defines the percentage of defects found in pre-production testing versus in
production. Tracking how many defects make it to production is a great way to evaluate the overall
quality of the software releases that you do. If you are finding too many issues in production, then
you know that you’re not doing a good job of automated testing, QA, etc. Therefore, you have to
improve your testing practices and try moving faster again. Your defect escape rate is a great constant
feedback loop to assess how your team performs.
In essence, the defect escape rate serves as a valuable feedback loop, guiding your team in refining
their testing practices and maintaining a balance between speed and quality in software
development.
Automation metrics
Since DevOps relies heavily on automation, it is crucial to understand what impact it has
created, when it comes to your deployment process. Given below are some of the metrics that
will help you quantify your automation efforts while trying to identify if there is a scope for
improvement:
• Deployment size per pipeline
• Deployment frequency
• Failed Deployments
Deployment size per pipeline
This metric measures the size or complexity of deployments pushed
through each pipeline. It helps understanding how much automation is
handled in each deployment cycle. Smaller deployment sizes generally
indicate more frequent, incremental updates, which are typically easier to
manage and less risky. Larger deployments might signify less frequent
releases, potentially increasing the risk of failures and making rollbacks
more complex.
Deployment frequency
This metric tracks how often deployments are pushed through the
pipeline. Higher deployment frequency often indicates more streamlined
and automated processes. It implies that the team is capable of delivering
changes quickly and efficiently, which is a key aspect of DevOps. It's
important to balance frequency with stability – while more frequent
deployments are generally desirable, they shouldn't compromise the
reliability of the system.
Failed Deployments
“Failed Deployments" refers to the number of times a deployment
process within the pipeline did not successfully reach its intended state,
essentially indicating a failed attempt to push code changes to a
production or staging environment, and is often measured as a
percentage of total deployments, called the "deployment failure rate.".
To calculate the failed deployment rate, divide the number of failed
deployments by the total number of deployments, resulting in a
percentage.