The present and future of CI/CD with GitOps on Red Hat OpenShift
The need to deliver applications faster is near-universal, even in organizations that traditionally are perceived as risk-averse. As the foundations of DevOps, continuous integration (CI) and continuous delivery (CD) are essential to application delivery in most organizations. Together, CI/CD tools and processes automate building and testing applications on every code or configuration change, then trigger a sequence of workflows that deliver the application to production.
Automation helps developers deliver quality applications faster while reducing human error, with proven results. As an example, Ford, one of the largest automakers in the United States, has accelerated their development process by adopting DevOps processes and CI/CD workflows, reducing their application delivery time to minutes instead of months.
Kubernetes and containers play an important role in reducing barriers to automating application delivery by providing the APIs and tools required to spin up infrastructure and deploy applications on demand. Automation on this level paved the way for many organizations to embark on a DevOps transformation, adopting not just the tools but the mindset and collaborative culture that comes with them. As the Kubernetes platform for developers, Red Hat OpenShift Container Platform was designed to support developer teams in adopting CI/CD practices and automating application delivery workflows.
In this article, we’ll look at how OpenShift is evolving to meet the future of CI/CD by integrating cloud-native tools such as Tekton, GitOps, and Argo CD. We’ll start with an overview of the present CI/CD landscape; then, I’ll introduce the technologies pointing us to the future.
CI/CD on OpenShift
The CI/CD landscape is constantly expanding to include a wider spectrum of tools and approaches to application delivery. Taking advantage of these tools presents an opportunity to improve your DevOps workflows. It also creates challenges due to existing investments in legacy and traditional tools. At Red Hat, we support development teams with their existing investments and workflows by ensuring that OpenShift integrates with existing toolsets. Here are just a few examples of the on-premises and cloud-based CI/CD services that are integrated with OpenShift:
- OpenShift Jenkins Plugin simplifies running actions against OpenShift from Jenkins pipelines.
- OpenShift Action for GitHub enables deployment into OpenShift directly from GitHub Action workflows in your GitHub repositories.
- OpenShift Extension for Azure DevOps offers tasks to integrate into Azure pipelines and perform actions on your OpenShift clusters.
- GitLab Runner for OpenShift integrates OpenShift with GitLab to run GitLab jobs on your OpenShift cluster and report the results back to GitLab.
As described in Figure 1, we are also engaging with current innovations in the Kubernetes open source CI/CD ecosystem in order to support teams focusing on cloud-native development and modern application delivery. Let’s start with how the technologies we listed earlier for automated builds, traditional CI/CD, and cloud-native CI/CD are coming together in OpenShift today.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
Development teams deliver code changes in the applications that they own to address business requirements. Building container images for the application and deploying to Kubernetes is often outside the focus of developers and disruptive to their workflows. Since the first OpenShift release, we’ve addressed this challenge with the OpenShift Build service. It provides build and deployment automation that runs on the platform and turns application source code into container images, which are then deployed to OpenShift. Every change to the application source code, configuration, or runtime updates (such as in Java or Node.js) leads to a new application image build, which is deployed thereafter. Developers who use Dockerfiles can curate exactly how they want their application container image to be built. Developers who prefer to point directly to their source code can use the Source-to-Image (S2I) strategy, which builds a container image from the application source.
Note: As the number of build tools in the Kubernetes ecosystem grows, OpenShift is expanding support for additional build tools such as Kaniko and Buildpacks, as well as through the next generation of the OpenShift Build capabilities base on the Shipwright open source project.
Continuous integration is a long-established practice in many organizations. Application development teams often start with Jenkins to automate building and testing their applications. Jenkins is a flexible, open source CI engine with a rich plug-in ecosystem.
To support this integration, OpenShift provides a Jenkins server and Jenkins agents for Node.js, Java, and .NET Core applications. Being able to easily run existing Jenkins pipelines on OpenShift lets teams take advantage of their long-term investments in the Jenkins ecosystem. Furthermore, Jenkins on OpenShift comes with a set of plug-ins that improve the Jenkins user experience on OpenShift and let you configure Jenkins servers declaratively.
Note: As teams adopt configuration-as-code to achieve repeatability for infrastructure deployment and configuration, we are receiving feedback from the Jenkins community and customers that it’s challenging to apply these practices to configuring the Jenkins server itself. While OpenShift plug-ins help alleviate this challenge, the configuration that is available is only a subset of the available configurations.
To address this problem and automate Jenkins’ operational management, we are working with the Jenkins community on a Jenkins Operator, which is available on OpenShift as a developer preview release. The Jenkins Operator applies the Operator pattern to installing and managing Jenkins servers on Kubernetes.
The increase in DevOps adoption and cloud-native development has spawned a need for CI/CD technologies that are adapted to the requirements of these new architectures, processes, and application paradigms. Despite using Jenkins as an established CI engine, many teams are seeking alternatives that are native to Kubernetes and build on the same infrastructure and abstractions that their applications do.
Tekton is an open source project and part of the Continuous Delivery Foundation, which is dedicated to creating a CI/CD framework that runs natively on Kubernetes. Tekton provides the ability to describe delivery pipelines declaratively using Kubernetes concepts and execute them on-demand in containers. OpenShift Pipelines builds on Tekton, delivering a stable and supported CI/CD experience that seamlessly integrates into OpenShift. With OpenShift Pipelines, we are sharply focused on providing the best possible user experience for Tekton pipelines.
Figures 2 and 3 show an example PetClinic application in OpenShift Pipelines and the OpenShift console.
As Kubernetes adoption has sped up and teams transition to continuous delivery, most organizations are grappling with the challenge of keeping their cluster configuration in sync and managing application delivery across hybrid, multi-cluster environments. While it’s common to build on CI for delivering applications to production environments, this strategy lacks the visibility and insight required to ensure that production clusters are consistent.
GitOps, an approach to continuous delivery and a subset of DevOps, is a set of practices that have become increasingly popular as a way to manage the complexities of running a hybrid multi-cluster Kubernetes infrastructure. GitOps supports developers in deploying applications to multiple Kubernetes clusters while guaranteeing consistency and predictability. Using Git repositories as the source of truth, GitOps allows developers to apply Git workflows that have been used for application development to infrastructure and application operators, hence providing visibility and traceability for every change that goes into production.
Argo CD is a declarative GitOps Operator that enables teams to implement GitOps patterns on Kubernetes. It automates deploying applications to multiple clusters by syncing the application configuration to the target clusters and ensuring that the clusters are in the desired state. Argo CD also monitors the state of the deployed applications on your Kubernetes clusters and increases security and reliability by constantly comparing them to the Git repositories. Argo CD is able to detect and correct any drift from the desired state (for instance, in case of manual changes). Red Hat recently joined the Argo community with the intention to collaborate and provide an integrated experience for developers implementing GitOps on OpenShift using Argo CD.
To recap, Tekton focuses on cloud-native CI/CD and delivery pipelines, and Argo CD focuses on visibility, traceability, security, and integrating GitOps practices. Combining Argo CD with Tekton provides a solid foundation for organizations starting their journey toward build-and-deployment automation and delivering cloud-native applications in hybrid multi-cluster environments.
We continue to expand the CI/CD capabilities on OpenShift to address the new and complex challenges teams are facing in multi-cluster environments. We are creating and integrating tools that assist teams to get started and establish CI/CD and GitOps practices across their organizations. The next OpenShift release will include a preview of these updates.