In the IT industry, it is common to use DevOps and CI/CD terms interchangeably. But they are not the same.

DevOps vs. CI/CD

DevOps is a methodology that allows streamlined software product development. In contrast, continuous integration and continuous delivery (CI/CD) is a development practice that lets us build and deploy code changes reliably. It’s a collection of operating principles that enables a project team to deliver code changes frequently and reliably. In other words, CI/CD can be imagined as the implementation of DevOps methodology.

Importance of CI/CD

Kaizen is a frequently used Japanese word in English to indicate continuous improvement. In a waterfall model, there is hardly any room for continuous improvement as there is no feedback loop. Sometimes, developers have had to wait for months before getting customer feedback. The purpose of CI/CD is to achieve continuous improvement. In some cases, CD refers to continuous deployment, and we’ll see the difference later in this lesson.

Imagine someone ordering a pizza from their favorite restaurant. They would want constant updates from when the order is placed until the pizza is baked and ready for pickup. If a pizza store is considering providing a continuous update to the customer about when a pizza will be prepared, it makes perfect sense that companies that invest millions of dollars would expect regular updates on the software production. This problem is what CI/CD solves.

Phases of CI/CD

A typical software project spans multiple phases. In the development phase, the developer starts producing the source code and checks into a source code repository. In the build phase, a build management tool like Jenkins builds the checked-in code. It generates the build artifacts that are uploaded after thorough testing. The QA team will perform functional and integration tests in the test phase and ensure that the application code addresses all the business requirements.

Typically, the development happens in a branch separate from the main branch. After the successful testing, the tested code is merged with the main branch and uploaded to a staging environment. Automated testing is triggered after every source commits, and changes are merged back to the main branch. This is the beginning of a successful continuous integration implementation.

In the deployment phase, the deploy tool or a script developed by the admin will push the tested artifacts to production. Some companies set up a manual approval phase before pushing the code to production, and some perform automated deployments directly to production. Deployment that requires manual approval is called continuous delivery. It is called continuous deployment if an automated process is followed from code commit to production deployment.

So, the manual approval process is the only differentiating factor between continuous delivery and continuous deployment.

In the monitoring phase, the customer support team will actively monitor the deployed software and alert the production support team if they observe any issues.

Benefits of CI/CD

Some of the quick benefits that a software team will realize once they implement a fully functional CI/CD process are as follows:

  • Fault isolation: Since all the phases of software development and delivery are isolated, issues can be quickly discovered at the point of failure.

  • Faster time to issue resolution: In the IT industry, this is called MTTR (short for mean time to resolution). CI/CD helps us to achieve lower MTTR in our project.

  • Easier and faster rollbacks: Since frequent deployments are happening, and the code changes are relatively smaller, a deployment can be easily rollbacked if there are issues in it.

  • Increased customer satisfaction: Since the code is released more frequently, the customer is constantly updated and informed of minor changes. This continuous feedback helps product teams address problems or issues at the first occurrence before it becomes too difficult to handle.

  • Cost reduction: Since the bug fixes are quickly detected and fixed, the software’s maintenance cost will be low.

Limitations of CI/CD

The limitations of CI/CD are as follows:

  • Missing configuration files in the repository: One of the most common mistakes is not checking all the application files in the same repository. By files, we refer not only to the source code but also to the properties files, manifest files, configuration files, and build scripts.

  • Lack of automation in the pipeline: For a CI/CD pipeline to be effective, the project team must automate the various phases. The successful completion of the current step must trigger the subsequent steps.

  • Frequency of code merge: The more the teams delay merging the changes from the development branch with the main branch, the harder it will be when they eventually do it. They face the probability of overwriting someone’s code changes, and the merged code will be more error-prone.

  • Insufficient metrics: A successful CI/CD pipeline requires monitoring tools at various phases. For example, a development team will be more interested in the team's velocity and burn-down rate. A QA team will be more interested in the number of issues opened per line of code. A network engineer in the operations team might be more interested in the status of the network, its bandwidth, and availability. So, setting the right metrics at every phase is crucial for a successful CI/CD pipeline.

  • Learning curve: Adopting the CI/CD process requires a change in mindset and skillset. Teams must quickly ramp up and understand the plethora of tools leveraged in setting up the CI/CD pipeline.

Critical metrics to measure DevOps performance

DORA (DevOps Research and Assessment) has published four key metrics to measure the stability and the velocity of a CI/CD pipeline.

  • Deployment frequency (DF): This metric measures how often code is deployed to production by the project team. Some of the top performers who have high-performing CI/CD pipelines release multiple deployments per day.

  • Mean lead time for changes (MLT): This metric is used to measure the time elapsed between a change committed to a branch and the time it gets deployed to production. Healthier teams have minimal time delays between these two events.

  • Mean time to recover (MTR): This metric measures the time it takes to restore the service in case of an unplanned outage or an incident. A smaller value indicates that the pipeline is highly resilient with a robust monitoring solution.

  • Change failure rate (CFR): This metric measures the frequency of code changes that led to production failures or outages. A large number indicates an ineffective testing plan being implemented in the pipeline.

The first two metrics are designed to measure the velocity, and the last two metrics are designed to measure the stability of a CI/CD pipeline.

Test your understanding

The picture below has seven different cards, each identifying a DevOps phase. They are not in the correct order. Try fixing the sequence of DevOps phases:

Rearrange the different phases and create the correct sequence for a typical DevOps implementation.