UNIT IV :: CI / CD

CI/CD : Introduction to Continuous Integration, Continuous Delivery and Deployment,

Benefits of CI/CD, Metrics to track CICD practices

******************************************************************************

Introduction
Developing and releasing software can be a complicated process, especially as applications,
teams, and deployment infrastructure grow in complexity. Often, challenges become more
pronounced as projects grow. To develop, test, and release software in a quick and consistent
way, developers and organizations have created three related but distinct strategies to manage
and automate these processes.

Continuous integration focuses on integrating work from individual developers into a main
repository multiple times a day to catch integration bugs early and accelerate collaborative
development. Continuous delivery is concerned with reducing friction in the deployment or
release process, automating the steps required to deploy a build so that code can be released
safely at any time. Continuous deployment takes this one step further by automatically deploying
each time a code change is made.
Software and application development industry has gone through tremendous changes in the past
decade.

From the good old days when software is installed on the desktop to the web-based SaaS
applications. And the transition is not just seen in the way applications are used but also in
the development methodologies — from the traditional waterfall development to Agile and the
new trend of DevOps. But all these changes and the introduction of new methods are aimed at
one thing — to enhance the development process and provide better products to the end user.
CI (Continuous Integration) and CD (Continuous Delivery/Deployment) are such methods that
are gaining momentum among developers using DevOps.

What is Continuous Integration and Why Is It Helpful?

Continuous integration is a practice that encourages developers to integrate their code into a
main branch of a shared repository early and often. Instead of building out features in isolation
and integrating them at the end of a development cycle, code is integrated with the shared
repository by each developer multiple times throughout the day.

The idea is to minimize the cost of integration by making it an early consideration. Developers
can discover conflicts at the boundaries between new and existing code early, while conflicts are
still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence
that the new code honours the requirements of the existing codebase.

Integrating code frequently does not, by itself, offer any guarantees about the quality of the new
code or functionality. In many organizations, integration is costly because manual processes are
used to ensure that the code meets standards, does not introduce bugs, and does not break
existing functionality. Frequent integration can create friction when an approach to automation
does not align with quality assurance measures in place.

To address this friction within the integration process, in practice, continuous integration relies
on robust test suites and an automated system to run those tests. When a developer merges code
into the main repository, automated processes kick off a build of the new code. Afterwards, test
suites are run against the new build to check whether any integration problems were introduced.
If either the build or the test phase fails, the team is alerted so that they can work to fix the build.
The end goal of continuous integration is to make integration a simple, repeatable process that is
part of the everyday development workflow in order to reduce integration costs and respond to
defects early. Working to make sure the system is robust, automated, and fast while cultivating a
team culture that encourages frequent iteration and responsiveness to build issues is fundamental
to CI success.

What is Continuous Delivery and Why Is It Helpful?

Continuous delivery is an extension of continuous integration. It focuses on automating the

software delivery process so that teams can easily and confidently deploy their code to
production at any time. By ensuring that the codebase is always in a deployable state, releasing
software becomes an unremarkable event, without any complicated rituals. Teams can be
confident that they can release whenever they need to without complex coordination or late-stage
testing. As with continuous integration, continuous delivery is a practice that requires a mixture
of technical and organizational improvements to be effective.

On the technology side, continuous delivery leans heavily on deployment pipelines to automate
the testing and deployment processes. A deployment pipeline is an automated system that runs
increasingly rigorous test suites against a build as a series of sequential stages. This picks up
where continuous integration leaves off, so a reliable continuous integration setup is a
prerequisite to implementing continuous delivery.

At each stage, the build either fails the tests, which alerts the team, or passes the tests, which
results in automatic promotion to the next stage. As the build moves through the pipeline, later
stages deploy the build to environments that mirror the production environment as closely as
possible. This way the build, the deployment process, and the environment can be tested in
tandem. The pipeline ends with a build that can be deployed to production at any time in a single
step.

The organizational aspects of continuous delivery encourage prioritization of “deployability” as

a principle concern. This has an impact on the way that features are built and hooked into the rest
of the codebase. Thought must be put into the design of the code so that features can be safely
deployed to production at any time, even when incomplete. A number of techniques have
emerged to assist in this area.
Continuous delivery is compelling because it automates the steps between checking code into the
repository and deciding on whether to release well-tested, functional builds to your production
infrastructure. The steps that help assert the quality and correctness of the code are automated,
but the final decision about what to release is left in the hands of the organization for maximum
flexibility.

What is Continuous Deployment and Why Is It Helpful?

Continuous deployment is an extension of continuous delivery that automatically deploys each

build that passes the full test cycle. Instead of waiting for a human gatekeeper to decide what and
when to deploy to production, a continuous deployment system deploys everything that has
successfully traversed the deployment pipeline. Keep in mind that when new code is
automatically deployed, new features can still be activated conditionally at a later time or for a
subset of users. Deploying automatically pushes features and fixes to customers quickly,
encourages smaller changes with limited scope, and helps avoid confusion over what is currently
deployed to production.

This fully automated deploy cycle can be a source of anxiety for organizations worried about
relinquishing control to their automation system of what gets released. The trade-off offered by
automated deployments is sometimes considered too dangerous for the payoff they provide.

Other groups leverage this approach as a means of ensuring that best practices are always
followed. Without a final manual verification before deploying a piece of code, developers must
take responsibility for ensuring that their code is well-designed and that the test suites are up-to-
date. This consolidates any decision-making around what and when to commit to the main
repository and what and when to release to production into a single decision point for the
development team.

Continuous deployment also allows organizations to benefit from consistent early feedback.
Features can immediately be made available to users and defects or unhelpful implementations
can be caught early before the team devotes extensive effort in an unproductive direction.
Getting fast feedback that a feature isn’t helpful lets the team shift focus rather than sinking more
energy into an area with minimal impact.
What is CI/CD?

Continuous Integration (CI) refers to committing (integrating) the code of individual

developers — several times a day into a repository and run an automated test. What this does is,
it helps to detect the issues and resolve them at a very early stage.

Continuous Delivery (CD) starts when the CI ends. Once the code is committed by the
developers, they are uploaded on the staging server. Here, the application is checked to ensure
that it’ll work well on the production server.

Continuous Deployment is a different concept than Continuous Delivery. CD here refers to the
deployment of the built directly to the server after the code is committed and passes the test.
Adopting Continuous Integration and Continuous Deployment enables producing new working
software at a faster rate.

Continuous Integration

Traditionally, the developers used to work on isolated features of the application, submit the
code and integrate it at the end of the cycle. This lead to spending several hours on tweaking the
code and resolving issues to get it working. This task was seeming difficult to deal with and cost
the developers more time, efforts that resulted in deadline pressures. In the development world,
this issue is known by the slang integration hell.

That’s when Continuous Integration comes it is a practice where developers integrate their code

into the main branch of the repository several times a day. The code is then validated by creating

a built and running automated tests. This continuous integration of small chunks of the codes —

typically several times a day results in a seamless and easy integration that saves time and effort.
Benefits of Continuous Integration

• Automated tests detect bugs at an early stage so that you can ship a clean final product to
the customers.

• Continuous Integration makes the release way easier and helps to avoid the integration
hell.

• Automated tests can run a number of tests at a time that reduces the overall cost of
testing.

• Even the quality analysts can focus on improving the quality of application cohesively
rather spending time on testing and finding bugs.

What You Need to Practice

• Maintain a common code repository where the developers can commit code — such as
GitHub and Gitlab.

• Automate the build.

• Configure the automated testing on the built package.

• Developers must commit the new code as often as possible typically several times a day.
Continuous Delivery

Continuous Delivery is an extension of Continuous Integration. It is a practice that enables the

developer to release the software on the production server with confidence.

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

Benefits of Continuous Delivery

• Continuous Delivery makes the application deployment painlessly easier and the team no
longer have to spend time on the release.
 • It also reduces the risk of deploying the application with bugs as they are detected early
on the production-like mock environment.

• Research has shown that CD making the releases easy and efficient reduces the burnout
and ultimately makes the team happier.

• Releases can be made quicker and more often resulting in faster customer feedback and
improving the product.

What You Need to Practice

• Your continuous integration must work well and the automated tests must cover enough
codebase.

• Once the deployment is triggered, it must be fully automated without any need for human
intervention.

• Incorporation of blue-green deployment or feature flags so that the incomplete features

do not create downtime and affect the users.

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. 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.
Benefits of Continuous Deployment

• Deliver the new changes to the customers as soon as they are developed.

• You get an early ROI for the new feature as it is available to the users quickly soon after
its development.

• Since small chunks of changes are released, it gets easier to fix the bugs.

• There is an incremental improvement in quality in a shorter period of time instead of

quarterly or yearly improvements.

What You Need to Practice

• Incorporation of feature flags is an integral part of the process.

• The changes are released as soon as the code is committed, built and tested. So the
quality of the new releases will be highly dependent on the testing.
What is CI/CD Pipeline?

Now you know that CI/CD is the strategies to ship well-tested applications frequently to the

customers — and making the development process fast and efficient. However, the success of

this discipline relies on a reliable CI/CD pipeline.

A CI/CD pipeline is the structure that automates the steps of the application delivery process.

Since the process is automated, it removes the chances of committing any manual error and

provides a quick product iteration. From a high-level view, the CI/CD pipeline includes steps

such as — code commit, build, automated testing and deployment on staging and production

server.

(An example of CI/CD Pipeline)

1. Commit

The pipeline starts with a common code repository where multiple developers working on the

application commits their code several times a day. Some of the popular and widely used code

repositories are GitHub, BitBucket, GitLab, Beanstalk and SourceForge.

2. Build

Now, the changes are built using a built management system. The source code is combined to

build a runnable component of the product.

3. Automate Testing

In this step, automated tests are run to check the codes. Automated testing plays an important

role in the entire CI/CD pipeline and the success of delivering bug-free application depends on it.

The code goes through varied tests depending on the complexity and needs of the project. We’ll

discuss the type of tests in a few moments. Popular tools for automated testing are Telerik Test

Studio, Selenium, Robotium, SoapUI and TestDrive.

4. Deploy

Once the built passes through the automated tests, they’re ready to be deployed. The deployment

can be either on the staging server, where the application is reviewed and additionally tested in

the mock environment that is similar to the production environment. Or can be directly deployed

onto the production server and made available to the users. Jenkins, Atlassian Bamboo, AWS

CodeDeploy and CICircle are the majorly used tools.

 (Deployment on the production-like staging server)

(Direct deployment on the production server)

The entire CI/CD pipeline is automated based on the needs of the project and organization. You
can either adopt Continuous Delivery where the changes are uploaded on the mock server and
then onto the production server or the highest level of automation — Continuous Deployment,
where the changes are reflected in the production server automatically once the code is
committed and passes the test.
Types of Automated Testing

Unequivocally, the key to successful continuous integration and continuous deployment/delivery

is automated testing. And without it, there can be no successful CI/CD pipeline. These automated

testing are divided into different types that serve their own purpose. The following are some of

the tests included in automated testing, though it is not necessary to include every test at once.

• Unit Testing – Unit testing is done to test individual classes or functions.

• Integration Testing – Integration tests make sure that the multiple modules of the
applications work well with each other.

• System Testing – System testing tests the entire system in an environment that replicates
the real production environment.

• UI Testing – UI testing is performed to make sure the application works great as per the
user’s perspective.

Wrapping Up

To wrap up, the ability to deliver the application, new features, components and bug fixes —

quickly and efficiently is a necessity to stay ahead in the competition. And CI/CD is one such

method that you can employ to meet the demands of modern software, web and mobile

development. Once you put it in place and practice the right CI/CD principles, it can reap

benefits for both your team as well as the end users.

Benefits of CI/CD

Releasing software can be a painful and time-consuming process. One involving weeks of
manual integration, configuration and testing while the ever-present risk of discovering a
showstopper threatens to force everyone back to square one. The time commitment involved in
getting code ready for release can mean changes are delivered every few months at best. But
there is another way.

Continuous integration, delivery and deployment (CI/CD) have enabled many organizations to
release on a more frequent basis without compromising on quality. With CI/CD, code changes
are shepherded through an automated pipeline that handles the repetitive build, test and
deployment tasks and alerts you about any issues.

If you’re wondering whether the benefits of continuous integration and delivery are worth
exploring, or you need help convincing your stakeholders, read on to find out what a difference a
CI/CD pipeline can make to your organization.

Faster time to market

The primary goal of a CI/CD pipeline is to deliver working software to users quickly and
frequently. Tech giants may have led the way, adopting Agile and DevOps techniques to
transform their development processes and deliver constant improvements to their users, but with
many smaller organizations following suit the landscape is becoming increasingly competitive.

Understanding your users’ needs, coming up with innovative features, and turning them into
robust code is not necessarily enough if your competition is moving more quickly. With an
automated CI/CD pipeline you can ship changes weekly, daily or even hourly.

New features can be launched faster, with deployment strategies giving you the option to
experiment and collect feedback, which you can then incorporate into the next update. Being
able to push changes out quickly and with confidence means you can respond to new trends and
address pain-points as they emerge.
Reduced risk

Having a shorter time to market doesn’t just help you keep up with the competition. Rapid
releases provide an opportunity for product managers and marketing professionals to engage
more closely with the development process.

Being able to test your innovations with users early and often – either with test participants in a
pre-production environment or with real users in live – means you can validate your approach
before investing months or even years working on a feature that doesn’t actually solve a problem
for your users.

Shorter review time

With continuous integration, developers are encouraged to commit their code changes more
frequently – at least once a day as a rule of thumb. Sharing code with the rest of the team
regularly not only ensures everyone is building on the same foundation, but also results in faster
code reviews and makes it easier to integrate changes.

Working with smaller increments means that – as a code reviewer – there is less to get your head
around. As smaller commits tend to produce more specific commit messages, you can more
easily see how the logic progresses. And if something does need to be changed before a commit
can be merged, there is less code to rewrite and fewer conflicts to resolve.

Better code quality

Testing your code’s behaviour is an essential step in the software release process but doing it
thoroughly can also be extremely time consuming. A central part of any CI/CD pipeline is a
series of automated tests that are run on each and every build. Although writing automated tests
requires an investment of time and expertise, doing so pays significant dividends.

As anyone who has had to follow a manual test script knows, testing is a repetitive process
demanding high levels of concentration. Even the most committed tester can be forgiven for the
occasional yawn as they reset their environment to perform the same steps with a single small
variation for the tenth or twentieth time.

Automating tests ensures they are performed consistently, making the results more reliable.
Because automated tests are quicker to run then their manual equivalents, it becomes feasible to
test much more frequently.

Testing your code regularly and thoroughly means you’ll discover bugs sooner, making it easier
to fix them as less functionality has been built on top of them. Over time this results in better
quality code.

Once you’ve invested in a first layer of automated tests, the time you save on running those tests
manually can be spent developing additional layers of automated tests – such as end-to-end or
performance tests – and on manual exploratory testing.

The latter puts your quality assurance or test engineers’ creative skills to use identifying new
failure modes while their findings can be used to extend your test coverage.

Smoother path to production

As we all know, practice makes perfect, and what’s true of shooting hoops or mastering scales
also applies to software releases. Adopting CI/CD is best done incrementally, starting with CI
practices and building up your pipeline over time. As you start deploying changes more
frequently you’ll identify pain points and steps in your current process that slow you down, such
as refreshing data in a test environment or having to reconfigure parameters before deploying on
a particular machine.

Adding automation for builds, tests, environment creation and deployments makes each step
consistent and repeatable. Having broken it down, you can keep optimizing each stage to make
your process more efficient. From being a significant event that occupies multiple teams for
several days, with CI/CD releasing matures into a familiar and predictable occurrence.
Faster bug fixes

Even with improved code quality thanks to automated testing, bugs will still occasionally sneak
their way through to production. If you’re committing changes regularly and shipping frequently,
each release to production will contain a relatively small number of code changes, making it
much easier to identify the cause of an issue. As your commits are more granular, if you decide
to back out the change, you’re less likely to take other useful changes with it.

When it’s urgent to get a fix out to production, it can be tempting to skimp on manual testing in
order to save time, despite the risk of introducing a new failure to production. With a CI/CD
pipeline, running automated tests is no longer a significant overhead, so there’s less temptation to
compromise on quality.

Efficient infrastructure

Automation is a central part of any CI/CD pipeline, serving to make the release process
repeatable and reliable. In the early stages of implementing continuous integration, your focus
will be on automating the build process and on writing and running automated tests. Once you’ve
established a solid CI foundation, the next stage is to automate deployment of your build to test
and staging environments.

Taking an infrastructure-as-code approach involves automating the creation of those

environments. Rather than managing individual servers manually, their configuration is scripted
and stored in version control so that new environments can be brought online quickly without the
risk of inadvertent changes and inconsistencies.

This not only makes the continuous delivery stage faster and more robust, but also allows you to
respond quickly to requests for additional preview and training environments with minimal
interruption to development work.
Measurable progress

Many of the tools available to support an automated CI/CD pipeline also instrument the process,
providing you with a whole host of metrics from build times to test coverage, defect rates to test
fix times. Armed with this data you can identify areas that might need attention so you can keep
improving your pipeline. Slower builds may indicate a need to increase capacity while an
increase in mean fix times might be a sign of a process or cultural issue.

Conversely, metrics can also provide reasons to celebrate, and so they should; consistently
extending your code test coverage, reducing your defect rate or increasing your release frequency
all belong on the team’s collective brag sheet as signs of a great working culture. Being able to
measure how your CI/CD pipeline is supporting your organization’s goals is another advantage
of the practice.

Tighter feedback loops

Rapid feedback is a key part of the DevOps approach with applications throughout the pipeline.
It starts with automated build and test steps to inform you of immediate problems, helping you to
work more efficiently and effectively than if there is a long delay between the original work and
the results.

Similarly, shipping updates regularly provides you with far more immediate feedback on what
you’ve built than if you batch changes up for a large release every few months. By collecting
feedback, observing user behaviour and tracking key performance indicators you can identify
what’s working well and prioritize modifications and improvements.

A frequent release cadence also gives you an opportunity to experiment with alternative designs
or behaviours – whether by running side-by-side comparisons with A/B testing, or by deploying
new versions and comparing results over time.

Feeding insights into a cycle of continuous deployment allows you to see how your changes
perform soon after you’ve made them. That means you can keep iterating and tweaking without
the loss of context that results from a long delay between coding and release.
Collaboration and communication

DevOps is as much about building a collaborative culture as it is about new processes and tools.
In order to get started with CI/CD you need to start breaking down barriers between teams and
encouraging more communication.

Aligning around the overarching aim of delivering a product that meets user needs and
understanding all the steps involved in reaching that goal helps everyone to focus on what needs
to be achieved rather than being limited by their team’s remit.

Breaking down silos between development and operations is the start of a virtuous circle.
A CI/CD pipeline provides an opportunity for the many functions and specialists involved in
building a product – from security experts to marketing teams – to get better visibility of the
software development process and to collaborate with each other more.

Many of the tools available to help manage your CI/CD pipeline also make it easier for non-
developers to see what is in train, while access to staging environments allows them to engage
with and provide feedback on what is being built. Sharing details of what is being released, usage
metrics and the results of experiments opens the door to more communication which in turn
fosters innovation.

Maximized creativity

As we’ve seen, building a CI/CD pipeline eliminates waste and helps create a leaner, more
efficient software development and release process. By using computers to perform repetitive
tasks, an automated process also frees up individuals to be creative. Instead of following manual
test scripts, refreshing environments, or deploying updates, you can focus on solving problems
and experimenting with solutions.

Having the scope to be more creative and add value in what you do leads to improved job
satisfaction, which encourages people to contribute more, attracts more talent and improves staff
retention. In turn that benefits your organization, your product, your users, and ultimately your
bottom line.

Metrics to track CICD practices

The primary goals of any DevOps practice revolve around three aspects: Time, Quality and
Speed. Based on different factors, the metrics can be grouped as follows:

1. Time-based metrics
2. Quality metrics
3. Automation metrics

1. Time-based metrics

One of the main objectives of DevOps is to save time and ship code as fast as possible. Hence,
gauging 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:

1. Time to market (TTM)

2. Defect resolution time
3. “Code freeze-to-delivery” time
4. 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.

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 the implementation of
your DevOps practices, there must be some process gaps that you need to identify and fix
immediately.

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

2. 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:
 1. Test pass rate
2. Number of bugs
3. 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.
However, you need to investigate if you are doing it the right way.

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 gauge 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.
 3. 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 understand if there is a scope for
improvement:

1. Deployment size per pipeline

2. Deployment frequency
3. Failed Deployments

Deployment size per pipeline

Deployment size or batch size is the number of story points such as feature requests, bug fixes,
etc. that have gone live per month/application. This number joins/attaches on the type of
application and the velocity of your team. However, it helps you get a glimpse of the outcome
that your CI/CD initiative has produced and is, therefore, an important metric to track.

Deployment frequency

Deployment frequency is a critical metric that indicates how your throughput performs during
your product and/or project development process. Companies like Amazon and Netflix deploy
code thousands of times every day, which proves they are doing DevOps right. Are you doing it
right? This is something you have to find out in order to streamline your pipeline.

Failed deployments

Have your code deployments made your customers irritated, time and again? Have there been
frequent outages and downtime as a result of your deployments? If yes, this is an indispensable
metric for your business.

Rolling back the deployments is not something teams prefer to do. However, if the frequency of
failed deployments is high, you have to plan for a quick rollback so it does not affect the
operational continuity of your business. Particularly, customer-facing businesses cannot afford
to incur frequent failures. It is therefore essential to track the failed deployments to deduce the
mean time to failure (MTTF).