What is Red Hat OpenShift Pipelines

Prepared by: Sultan Öztürk – SEKOM SD-X & Cloud Technologies Engineer

What is CI/CD?

Red Hat summarizes CI/CD processes as the “processes that automate the stages of creating, testing, and deploying applications.” In the traditional setup, business processes between software teams and other units were done manually, causing confusion. The goal was to eliminate this confusion by automating these business processes, and this is how the CI/CD concept emerged.

CI refers to Continuous Integration, an automation process for developers. Successful CI means that new code changes in an application are regularly built, tested, and merged into a shared pool. This solves the issue of having too many conflicting branches in an application being developed simultaneously.

CD, as related concepts, can sometimes be used interchangeably to mean Continuous Deployment and/or Continuous Delivery. Both of these terms are concerned with automating the subsequent stages of a pipeline. Continuous Delivery typically refers to a process where changes in the application are automatically error-tested and then uploaded to a repository, where it can later be deployed to a production environment by operations teams. This process helps solve communication issues between development and operations teams and ensures that minimal effort is required to deploy code.

Continuous Deployment means automatically transferring changes made by a developer into an environment where the application is available to customers. This addresses the issue of overloading operations teams with manual processes

What is Cloud-Native CI/CD?

Cloud-native is a broad concept, but its key aspects in CI/CD processes include being suitable for container infrastructure, being serverless, and being designed by DevOps teams in a way that fits these infrastructures. Being based on container infrastructure means that you can run applications orchestrated by Kubernetes in their appropriate form. Being serverless allows applications to be run and scaled on-demand without needing to maintain a central CI engine, while DevOps teams can design solutions that are tailored to microservice architectures, making tasks more easily shareable among teams.

OpenShift Pipelines and Tekton

There are several product options available for creating pipelines, such as Jenkins, JenkinsX, and Spinnaker. However, OpenShift offers its own solution — OpenShift Pipelines — built on Tekton, a powerful and flexible tool designed with cloud-native features. OpenShift Pipelines enhances Tekton by adding additional privileges and platform-specific features, offering a tailored solution that can be integrated into the OpenShift platform with the help of an operator.

OpenShift Pipelines makes it easier to create build pipelines. By using CRDs (Custom Resource Definitions), you can reuse a pipeline across different projects. It consists of components like Tekton Step, Task, Pipeline, TaskRun, and PipelineRun.

Step is one of the operations performed in your code. These can be unit tests, checks to ensure the code complies with existing coding standards, or may involve any command or script. In other words, steps are the most basic tasks in Tekton.

Tasks are a collection of steps. These tasks run on Kubernetes pods, providing a shareable environment. You can mount a volume to a task and use it across all steps. Tasks can be defined as Custom Resources. Each task runs in a pod, so tasks within a pipeline do not share data by default. To share data between tasks, you need to specify explicitly which task will use the output of the previous task.

A Pipeline is a collection of tasks; in other words, a pipeline is formed by chaining tasks together. Tasks in a pipeline can be executed sequentially or in parallel. Tekton gives developers flexibility on when and how tasks should execute. For example, you can define conditions that must be met for a task to trigger the next one. Pipelines can also be defined as Custom Resources.

A pipeline is a process with inputs and outputs. Each task and pipeline will have its own specific inputs and outputs. The beauty of reusable Tekton pipelines is that the pipeline you create for building, testing, and packaging an application can be reused for different inputs that follow the same workflow. For example, you might want a Git repository as input and an image as output for your pipeline, and if necessary, you can reuse this for different code-based applications. Information such as the Git repository, registry, or other specific details are taken as CRDs defined during PipelineRun or as parameters defined while running the pipeline.

Contact our experienced Sekom SD-X & Cloud team to make your transformation efficient!