What is CI/CD?

Copy URL

CI/CD, which stands for continuous integration and continuous delivery/deployment, aims to streamline and accelerate the software development lifecycle.

Continuous integration (CI) refers to the practice of automatically and frequently integrating code changes into a shared source code repository. Continuous delivery and/or deployment (CD) is a 2 part process that refers to the integration, testing, and delivery of code changes. Continuous delivery stops short of automatic production deployment, while continuous deployment automatically releases the updates into the production environment.

 

CI/CD Flow

 

Taken together, these connected practices are often referred to as a "CI/CD pipeline" and are supported by development and operations teams working together in an agile way with either a DevOps or site reliability engineering (SRE) approach.

CI/CD helps organizations avoid bugs and code failures while maintaining a continuous cycle of software development and updates. 

As apps grow larger, features of CI/CD can help decrease complexity, increase efficiency, and streamline workflows.

Because CI/CD automates the manual human intervention traditionally needed to get new code from a commit into production, downtime is minimized and code releases happen faster. And with the ability to more quickly integrate updates and changes to code, user feedback can be incorporated more frequently and effectively, meaning positive outcomes for end users and more satisfied customers overall. 

Platform engineering vs. DevOps

The "CI" in CI/CD always refers to continuous integration, an automation process for developers that facilitates more frequent merging of code changes back to a shared branch, or “trunk.” As these updates are made, automated testing steps are triggered to ensure the reliability of merged code changes. 

In modern application development, the goal is to have multiple developers working simultaneously on different features of the same app. However, if an organization is set up to merge all branching source code together on one day (known as “merge day”), the resulting work can be tedious, manual, and time-intensive. 

That’s because when a developer working in isolation makes a change to an application, there’s a chance it will conflict with different changes being simultaneously made by other developers. This problem can be further compounded if each developer has customized their own local integrated development environment (IDE), rather than the team agreeing on one cloud-based IDE.

CI can be thought of as a solution to the problem of having too many branches of an app in development at once that might conflict with each other.

Successful CI means that once a developer’s changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated testing, typically unit and integration tests, to ensure the changes haven’t broken the app. This means testing everything from classes and function to the different modules that comprise the entire app. One of the benefits of CI is that if automated testing discovers a conflict between new and existing code, it is easier to fix those bugs quickly and often.

The "CD" in CI/CD refers to continuous delivery and/or continuous deployment, which are related concepts that sometimes get used interchangeably. Both are about automating further stages of the pipeline, but they’re sometimes used separately to illustrate just how much automation is happening. The choice between continuous delivery and continuous deployment depends on the risk tolerance and specific needs of the development teams and operations teams.

 Continuous delivery automates the release of validated code to a repository following the automation of builds and unit and integration testing in CI. So, in order to have an effective continuous delivery process, it’s important that CI is already built into your development pipeline.

In continuous delivery, every stage—from the merger of code changes to the delivery of production-ready builds—involves test automation and code release automation. At the end of that process, the operations team is able to swiftly deploy an app to production.

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository (like GitHub or a container registry), where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between dev and business teams. To that end, the purpose of continuous delivery is to have a codebase that is always ready for deployment to a production environment, and ensure that it takes minimal effort to deploy new code.

Learn more about continuous delivery

The final stage of a mature CI/CD pipeline is continuous deployment. Continuous deployment is an extension of continuous delivery, and can refer to automating the release of a developer’s changes from the repository to production, where it is usable by customers.

CD addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline.

In practice, continuous deployment means that a developer’s change to a cloud application could go live within minutes of writing it (assuming it passes automated testing). This makes it much easier to continuously receive and incorporate user feedback. Taken together, all of these connected CI/CD practices make the deployment process less risky, whereby it’s easier to release changes to apps in small pieces, rather than all at once. 

However, because there is no manual gate at the stage of the pipeline before production, continuous deployment relies heavily on well-designed test automation. This means that continuous deployment can require a lot of upfront investment, since automated tests will need to be written to accommodate a variety of testing and release stages in the CI/CD pipeline.

Learn more about deployment automation

CI/CD is an essential part of DevOps methodology, which aims to foster collaboration between development and operations teams. Both CI/CD and DevOps focus on automating processes of code integration, thereby speeding up the processes by which an idea (like a new feature, a request for enhancement, or a bug fix) goes from development to deployment in a production environment where it can provide value to the user.

In the collaborative framework of DevOps, security is a shared responsibility integrated from end to end. It’s a mindset that is so important, it led some to coin the term "DevSecOps" to emphasize the need to build a security foundation into DevOps initiatives. DevSecOps (development, security, and operations) is an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle. A key component of DevSecOps is the introduction of a secure CI/CD pipeline.

Like DevOps, platform engineering shares the common goal of strengthening the integration of developers and operations teams by increasing automation and collaboration. The adoption of DevOps and CI/CD resulted in longer pipelines and toolchains, and as a result developers have become responsible for understanding more and more of the intricacies involved in the applications they’re building.

To meet these challenges, platform engineering has emerged as a complementary discipline to address the challenges of scaling DevOps across organizations. Platform engineering as a strategy builds upon DevOps by finding better ways to automate application delivery, improve collaboration and communication, reduce error, enhance security and compliance, increase efficiency, and most importantly, refocus the strengths of developers where their effort is most needed. 

Why choose Red Hat for DevOps?

CI/CD security is used to safeguard code pipelines with automated checks and testing to prevent vulnerabilities in software delivery. Incorporating security into your pipeline--via methods like shift left and shift right security--helps to protect code from attack, prevent data leaks, comply with policies, and ensure quality assurance.

The rapid nature of development and deployment without proper security can expose the pipeline to risks, such as:

  • Exposure of sensitive data to outside sources
  • Use of insecure code or third party components
  • Unauthorized access to source code repositories or build tools

Identifying and mitigating vulnerabilities throughout the software development cycle assures that code changes are thoroughly tested and adhere to security standards before being deployed to production.

Resource

Platform engineering drives DevSecOps and software security

Read more about how platform engineering improves security, productivity, and DevOps standardization.

Red Hat Developer Hub

A Backstage-based open enterprise platform for building developer portals that visually consolidates elements of the development process.

Keep reading

What is blue green deployment?

Blue green deployment is an application release model that gradually transfers user traffic from a previous version of an app or microservice to a nearly identical new release—both of which are running in production.

What is observability?

Observability refers to the ability to monitor, measure, and understand a system or application by examining its outputs, logs, and performance metrics.

How to approach DevOps metrics

DevOps metrics track the effectiveness of DevOps practices, which relate to software development and IT operations.

DevOps resources