What is CI/CD?

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.

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. 

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.

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.

CI/CD tools can help a team automate their development, deployment, and testing. Some tools specifically handle the integration (CI) side, some manage development and deployment (CD), while others specialize in continuous testing or related functions.

Tekton Pipelines is a CI/CD framework for Kubernetes platforms that provides a standard cloud-native CI/CD experience with containers.

Learn more about Tekton Pipelines 

Beyond Tekton Pipelines, other open source CI/CD tools you may wish to investigate include:

• Jenkins, designed to handle anything from a simple CI server to a complete CD hub
• Spinnaker, a CD platform built for multicloud environments.
• GoCD, a CI/CD server with an emphasis on modeling and visualization.
• Concourse, "an open-source continuous thing-doer."
• Screwdriver, a build platform designed for CD.

Teams may also want to consider managed CI/CD tools, which are available from a variety of vendors. The major public cloud providers all offer CI/CD solutions, along with GitLab, CircleCI, Travis CI, Atlassian Bamboo, and many others.

Additionally, any tool that’s foundational to DevOps is likely to be part of a CI/CD process. Tools for configuration automation (such as Ansible, Chef, and Puppet), container runtimes (such as Docker, rkt, and cri-o), and container orchestration (Kubernetes) aren’t strictly CI/CD tools, but they’ll show up in many CI/CD workflows.

There are many different ways you can implement CI/CD based on your preferred application development strategy and cloud provider. Red Hat® OpenShift® Service on AWS has several options available to make your own CI/CD workflow easier like Tekton and OpenShift Pipelines. By using Red Hat OpenShift, organizations can employ CI/CD to automate building, testing, and deployment of an application across multiple on-premises and cloud platforms. 

Our experts can help your organization develop the practices, tools, and culture needed to more efficiently modernize existing applications and accelerate your cloud-native application development journey.

Red Hat® OpenShift® helps organizations improve developer productivity, automate CI/CD pipelines, and shift their security efforts earlier and throughout the development cycle.

Red Hat OpenShift Pipelines is designed to run each step of the CI/CD pipeline in its own container, allowing each step to scale independently to meet the demands of the pipeline. This means admins and developers can create pipeline blueprints for applications that are based on their organization’s unique business and security requirements.

Red Hat OpenShift GitOps is an operator that provides a workflow that integrates git repositories, continuous integration/continuous delivery (CI/CD) tools, and Kubernetes to realize faster, more secure, scalable software development, without compromising quality.  OpenShift GitOps enables customers to build and integrate declarative git driven CD workflows directly into their application development platform.

Red Hat Ansible® Automation Platform includes all the tools you need to implement automation across your organization, including an event-driven solution, analytics, and pre-built content collections. With its common YAML-based language and desired-state approach, you can use the same automation content for everyday operations as well as your CI/CD pipeline. And because it works with nearly all aspects of your IT infrastructure, you can more easily and quickly deploy consistent development, test, and production environments, increasing the reliability and resiliency of your applications.

Ansible Automation Platform also integrates with Red Hat Advanced Cluster Management for Kubernetes, allowing you to orchestrate Kubernetes clusters within your CI/CD pipeline. You can also use the human-readable automation language to more easily build and maintain Red Hat OpenShift operators.

Learn more about how automation supports CI/CD pipelines