From code to production with OpenShift Pipelines and Argo CD
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:
- Red Hat OpenShift 4.5.4 cluster:
- Demo application:
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
Argo CD and OpenShift Pipelines
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.
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:
- The application repository (
- Use: Stores the source code for our application.
- Webhooks: Notifies Tekton when new commits hit the main branch.
- The application CI/CD repository (
- 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.
The workflow is as follows:
- Developers send new commits to the application repository.
- GitHub notifies Tekton.
- Tekton lints, tests, builds, and pushes a new container image with the new code to Quay.io.
- Tekton updates the deployment file for the stage environment in the application CI/CD repository with the new image version.
- GitHub notifies Argo CD.
- Argo CD runs the application deployment for staging.
The promotion pipeline
Figure 2 shows the workflow for the promotion pipeline.
The workflow is as follows:
- Developers run the promotion pipeline.
- 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.
- Once the PR is merged, GitHub notifies Argo CD.
- 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.
Figure 4 shows the 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.
Next is the production application, shown in Figure 6.
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
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
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.
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.