Article

From code to production with OpenShift Pipelines and Argo CD

September 10, 2020
CI/CDDevOpsKubernetes
Mario Vázquez
Software Engineer
A diagram of the build pipeline workflow.

Our team is responsible for a small GoLang application. The application's developers are continuously sending code changes to the main branch, so for the past two years, our team has used GitOps for continuous integration (CI). We started out using GitOps to deploy applications to our test clusters; then, we began using it to run day two operations in our clusters.

From there, we chose Argo CD as our continuous deployment (CD) tool. When we started, it was the best fit for our workflows. It works perfectly as a GitOps tool, and it's easy to integrate with Red Hat OpenShift.

When OpenShift Pipelines was released, we decided to try it because our applications would benefit from an automated CI pipeline. We started creating pipelines to automatically build our apps whenever a new commit hit the main branch. Once we had enough experience with these tools, we considered automating our CI and CD workflows so we wouldn't need to worry about anything but writing code.

This article includes a demonstration of our CI/CD pipeline, and shows you how to set up a demonstration environment so that you can run the example application detailed below on your own. I'll also show you two videos of the build and production pipelines in action.

Set up your demo environment

To follow the examples in this article, will need the following installed in your development environment:

Argo CD and OpenShift Pipelines

First, here's a quick introduction to Argo CD and OpenShift Pipelines. Argo CD is a tool for doing GitOps continuous delivery on Kubernetes in a declarative way. You can learn more about GitOps here.

OpenShift Pipelines is a CI/CD solution based on Tekton. It adds onto Tekton's building blocks and provides a CI/CD experience through tight integration with OpenShift. You can learn more Tekton here.

Application scenario

We want every new commit to the main branch to be linted, tested, built, and deployed in our staging environment, without manual intervention. So, the example application features a continuous integration pipeline that is in charge of linting, testing, and building the code. Argo CD manages continuous deployment and is configured to deploy the application to the staging and production environments.

We use webhooks in Git to automatically trigger pipelines and deployments when new commits hit specific branches in our repositories.

The CI pipelines

We have two different pipelines: One that builds the code and deploys to staging, and one that promotes staging builds to production. Before we talk about the pipelines, let's review the two Git repositories that we will be using:

  1. The application repository (reverse-words):
    • Use: Stores the source code for our application.
    • Webhooks: Notifies Tekton when new commits hit the main branch.
  2. The application CI/CD repository (reverse-words-cicd):
    • Use: Stores the CI manifests (Tekton configurations), and the deployment manifests (Used by Argo CD).
    • Webhooks: Notifies Argo CD when deployment files are updated.

The build pipeline

Figure 1 illustrates the workflow for the build pipeline.

A diagram of the build pipeline workflow.
Figure 1: The build pipeline workflow from the developer to staging.

The workflow is as follows:

  1. Developers send new commits to the application repository.
  2. GitHub notifies Tekton.
  3. Tekton lints, tests, builds, and pushes a new container image with the new code to Quay.io.
  4. Tekton updates the deployment file for the stage environment in the application CI/CD repository with the new image version.
  5. GitHub notifies Argo CD.
  6. Argo CD runs the application deployment for staging.

The promotion pipeline

Figure 2 shows the workflow for the promotion pipeline.

A diagram of the promotion pipeline workflow.
Figure 2: The promotion pipeline workflow from developer to production.

The workflow is as follows:

  1. Developers run the promotion pipeline.
  2. Tekton runs tests on the staging environment; if everything is okay, it opens a push request (PR) into the application CI/CD repository updating the deployment file for the production environment.
  3. Once the PR is merged, GitHub notifies Argo CD.
  4. Argo CD runs the application deployment for production.

Ready to deploy?

Let's take a look at the two pipelines we configured in our OpenShift cluster. Figure 3 shows the build pipeline.

Reverse words build pipeline
Figure 3: The reverse-words build pipeline.

Figure 4 shows the promotion pipeline.

Reverse words promotion pipeline

Figure 4: The reverse-words promotion pipeline.">

We already created the Argo CD applications, so let's take a look at those next. First is the staging application, shown in Figure 5.

Reverse words staging application
Figure 5: The state of each component in the reverse-words staging application.

Next is the production application, shown in Figure 6.

Reverse words production application
Figure 6: The state of each component in the reverse-words production application.

At this point, we have everything ready to create a new application and then build and deploy it automatically. Let's check the application versions we're running at the moment. Figure 7 shows the stage application version after entering the following commands:

$ oc -n reverse-words-stage get route -l app-reversewords-stage
$ curl http://reversewords-dev.apps.codetoprod.b999.sandbox313.opentlc.com
A screenshot of the stage application config in the console.
Figure 7: Check the stage application version in the console.

Figure 8 shows the production app version after entering the following commands:

$ oc -n reverse-words-production get route -l app-reversewords-prod
$ curl http://reversewords-prod.apps.codetoprod.b999.sandbox313.opentlc.com
A screenshot of the production application config in the console.
Figure 8: Check the production application version in the console.

On staging, we are running the demo application's version 0.0.14 release, and on production, we are running application version 0.0.13. Next, we will create a new build, version 0.0.15, and have it deployed automatically to staging. If everything works, we will then promote this new build to production.

See the demo app in action

In the first video below, we update the application to version 0.0.15 and push the changes to the Git application repository. When the commit hits the main branch, a new PipelineRun is created. The pipeline lints, tests, and builds our code. Finally, it updates the application deployment file for the staging environment in the application CI/CD repository. Once the deployment file is updated, the staging application is updated automatically.

All of this is shown in the "Build Pipeline" video.

In the "Promote Pipeline" video, we promote the stage release to production. First, the pipeline queries the stage application to ensure that everything is running correctly. Then, it uses a PipelineRun to update the application deployment file for the production environment in the application CI/CD repository. Once the PipelineRun is merged, and thus the deployment file is updated, the production application is automatically updated.

What's next?

You can start using Tekton and Argo CD today. If you don't know where to begin, we have a few Katacoda scenarios that you can try:

If you want to run the demo from this article in your own environment, you will find everything you need in the demo repository. And if you already have experience with using Tekton, we encourage you to have a look at the Tekton Hub. You can use the hub to contribute your tasks and pipelines so that the community can benefit from them.

Last updated: September 8, 2023