In the old days, shipping code was a nightmare. To release a bit of new functionality was complex and time consuming - sometimes several days! One of the main problems with it, was that the integration of all new components was done at the same time: the release day.

Over the years, as our industry needed to release more functionality, more frequently, we improved the way software is built, tested and deployed. First, we conceived the concepts of Continuous Integration and Continuous Delivery. More recently, the need for version control over the releases and infra changes brought about the term GitOps, a set of practices that empowers developers to develop cloud native applications continuously.

But what is HAT?

HAT is the acronym for Helm, ArgoCD and Tekton. Tekton is a cloud native continuous integration and delivery (CI/CD) solution. It allows developers to build, test, and deploy across cloud providers and on-premise systems. Helm is a template system that helps us manage complex Kubernetes applications. And ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.

Let’s explore an example of how these three tools can work together. 

Imagine that we have a web application that we need to promote between different environments.

CI 

The first step will be to create a pipeline to build, test and deploy our app. There are a lot of different solutions on the market that are easy to use. But they have some downside. For example: gitlabci makes it difficult to share steps/tasks between different pipelines/repositories, while Jenkins has the problem of versioning its configuration, although some plugins can help with that. 

Tekton resolves the first problem by introducing the concept of Task, that will allow us to share between different pipelines. The second problem will be solved using ArgoCD to install Tekton manifests.

With Tekton, platform engineers can create tasks that may then be used by developers in their own pipelines. For our example, in our web application there is a folder with the Helm chart that has the needed pipeline manifest. This pipeline will reference tasks that are already in the cluster where Tekton runs.

In this way the web service developer has full control of the CI pipeline, empowered to choose existing tasks or create new ones. And every change will be versioned as it will be in a git repository.

CD

For Continuous Delivery, we will use the following approach. The service definition will be as a Helm chart inside of the repo. This chart will be packaged and pushed to a Helm repository every time a change inside the repository is done. 

The objective that we wish to achieve here is to avoid divergences between the service version and the chart version.

To represent the different environments, there will be a “repo per env”. For our app we will have three: test, stage and prod.

With that we can have better security policies, allowing all developers to access the test repository but restricting the other two repositories to senior developers and DevOps.

All the charts in those repositories extend from charts in the chart repository and only values that are environment specific - for example, the environment variables which store the connection string to a database. 

Connecting CD and CI, the missing part

As we don’t want to have any environment configuration inside the application repo, we will have Tekton tasks that will be created by the SRE, which developers may reference in their pipeline.

These tasks will commit the new image tag to the app folder of the proper git ops repository depending on the branching model that will be defined in the pipeline.

For example for this application, we will have three tasks: TaskDeployTest, TaskDeployStage and TaskDeployProd. They have as input the application name and the tag that we wish to deploy. The TaskDeployTest task has configured the permissions to push to the test-cluster repository, while the TaskDeployStage will do the same for stage and TaskDeployProd for production environment.

Advantages 

  • We have all CI/CD configuration managed with a version control system, so we can track the changes and easily roll back changes if needed.
  • The repo has all service configuration, providing an easy way to sync service code changes with service configuration changes.
  • Thanks to the use of a chart repo, we will avoid divergences in the service configuration between the different environments.
  • Reuse of tasks improves pipeline development speed.

Disadvantages

  • Configuring Tekton to listen for changes in the repositories is not out-of-the-box.
  • Developers have to learn how to handle manifests, making the adoption of this type complicated.

This could be simplified by creating the Helm chart for the pipeline with the minimum configuration and above all with good documentation.