Platform9 Blog

Argo CD vs Tekton vs Jenkins X: Finding the Right GitOps Tooling

Introduction

In this article, we’re going to take a look at three different CI/CD tools that have grown in popularity over the last couple of years: Argo CD, Tekton, and Jenkins X.

If you’re reading this article, you’re either considering implementing GitOps in your organization to manage your operational workflows, or you’ve already done so. You have probably also considered cloud-native platforms and tooling such as Kubernetes. In order to implement GitOps with Kubernetes, it’s crucial to carefully choose CI/CD tools that make sense for your use case.

We’ll assume that you are already familiar with GitOps and Kubernetes. If not, read our article here or access a wealth of resources on the web that explains each of them at almost any level of detail you could want. Gitlab provides a great video on the topic of GitOps. In addition, the Kubernetes documentation itself provides a clear explanation that should get you started.

Criteria for Comparing Argo CD vs Tekton vs Jenkins X

To provide an apples-to-apples comparison, we will evaluate each one on the following criteria:

  • Deployment and Ease of Use
  • Integrations and Configurability
  • How Tuned Is It for Kubernetes?
  • Coverage of GitOps Workflow 
  • Community, Maturity, and Popularity

With that said, let’s dive right in.

At a Glance Comparison

The following table compares each project according to the criteria discussed above.  You can use it as a cheat sheet for your own comparison.

ArgoCDTektonJenkins X
DeploymentSimpleComplexModerate
Ease of UseSimpleComplexModerate
IntegrationsExcellentExcellentGood
ConfigurabilityGoodExcellentOk
Tuned for KubernetesYesYesYes
GitOps Workflow CoverageCD OnlyCI/CDOpinionated CI/CD with additional automation features
CommunityGoodGoodGood
MaturityExcellentGoodOk
PopularityExcellentGoodOk

Argo CD

Argo CD was developed by Intuit and released as open-source under the Apache 2.0 license at the beginning of 2018. Intuit was initially using Spinnaker, but they wanted something lighter weight that would improve their build and deployment times as well as streamline their GitOps workflow when using Kubernetes.

Argo CD bills itself as a declarative GitOps Continuous Delivery (CD) tool for Kubernetes. At a high level, there are a few key features to note:

  • Ability to deploy and sync applications to Kubernetes clusters automatically or manually
  • Drift detection, correction, reporting, and visualization via the UI
  • Support for multiple Kubernetes clusters and multi-tenancy with RBAC
  • SSO via a number of providers including GitHub, GitLab, Microsoft, LinkedIn, OAuth2, SAML 2.0, LDAP, and OIDC
  • WebUI and CLI
  • Support for webhooks via Github, BitBucket, and GitLab

A full list of features with more detailed descriptions can be found on the Argo CD Overview page in the documentation.

Deployment and Ease of Use

Deployment to a live Kubernetes cluster is simple and requires only two commands using kubectl. The CLI installs on your local machine and is supported on Windows, Mac, and Linux.

Once the initial installation is done, you’ll run a few commands to configure Argo CD for your use case. These are clearly laid out on the Getting Started page in the documentation. There is also an option to deploy a sample app for those who want to give it a spin.

Argo CD’s well-developed UI makes it extremely easy to use, even for novices. Apps can be deployed and synced via the UI or CLI. Details on resource components, status, history, logs, events, and application health are all visible in the UI.

Integrations and Configurability

Argo CD integrates well with common CI tools including Jenkins, Github Actions, CircleCI, Gitlab CI, and so on. It supports webhooks via Github, Bitbucket, and Gitlab.

You can find numerous examples of how to integrate it with managed Kubernetes providers such as EKS, GKE, and AKS on the web.

It supports most common SSO providers including GitHub, GitLab, Microsoft, LinkedIn, OAuth2, SAML 2.0, LDAP, and OIDC.

ArgoCD supports multiple ways to define Kubernetes manifests, including Kustomize, Helm, Ksonnet, Jsonnet, JSON, and YAML. It also gives you the option to define a custom configuration management plugin if you want that level of customization.

How Tuned Is It for Kubernetes?

Argo CD was designed from the start to fully support Kubernetes, and it only runs on Kubernetes. It is deployed to your Kubernetes cluster, and it integrates with your cluster in its own namespace using Custom Resource Definitions.

It works by monitoring your Git repository for changes to the Kubernetes manifests that define your application. When it detects changes, it will automatically publish them to the target cluster. If needed, changes can also be synced manually via the UI or the CLI.

One major advantage of Argo CD is its support for multi-tenancy and multiple Kubernetes clusters. This includes the ability to deploy multiple applications to multiple clusters if desired. Its support for RBAC means that teams can deploy applications to their own namespaces without the risk of affecting other teams’ applications that are running in a different namespace.

Coverage of GitOps Workflow

Argo CD aims to be a lightweight tool with limited scope, so it does not provide Continuous Integration (CI) features such as application testing and building. For that, you will need to choose your own CI tools, such as CircleCI, Github Actions, Gitlab CI, or Jenkins.

This could be viewed as an advantage since it gives engineering teams more flexibility in choosing which CI tool they think is best for their use case. On the other hand, CI isn’t included out of the box, and it needs to be configured separately (although it will integrate easily via mechanisms such as webhooks and the CLI).

Community, Maturity, and Popularity

As it was released in 2018, Argo CD is only about three years old. That said, it is in active development with multiple updates per week, and based on its scope and features, it can be considered a mature project. There are many notable names on the long list of companies that use Argo CD, including Intuit, Red Hat, Sumo Logic, Ticketmaster, Twilio, and Volvo.

Tekton

Tekton was originally part of the Knative project and is now under the auspices of the Continuous Delivery Foundation. Like Argo CD, Tekton was released in 2018 under the Apache 2.0 license.

Tekton takes a modular approach to cloud-native CI/CD by implementing components that form the building blocks needed to create a complete CI/CD ecosystem. Due to its nature, Tekton is extremely powerful, and it provides the ability to customize entities which can then be shared and reused as needed.

The biggest selling point of Tekton is its modularity, which allows for componentization, standardization, and reusability within your CI/CD workflows. The steps are operations in the CI/CD workflow that execute in containers, and they are organized into tasks that run as pods on your cluster. Tasks can be assembled and ordered within pipelines in any way that you need.

Deployment and Ease of Use

The initial installation of Tekton to your Kubernetes cluster requires only a single command. The Tekton CLI installs to your local machine, and it’s supported on Mac, Windows, and Linux.

In terms of ease of use, there is definitely a learning curve with Tekton. You need a solid understanding of CI/CD and your own requirements before it becomes truly useful. For anything beyond simple workflows, the onus is on the developer to assemble the necessary pieces into a complete CI/CD workflow.

Tekton does have a modular and extensible dashboard that provides visibility and management features; but again, additional configuration is required to make it usable for your use case.

Integrations and Configurability

Tekton’s strength is its modularity and flexibility, which allows for the assembly of complex pipelines without the need to rewrite the building blocks every time. Tekton has a catalog of pre-defined, reusable task resources, and it aims to provide more catalog features as the project progresses.

Since it will run on Kubernetes, it will integrate well across providers including AKE, GKE, EKS, or a “roll your own” Kubernetes cluster. It will also work with other CI/CD tools such as Jenkins, Jenkins X, and Skaffold.

How Tuned Is It for Kubernetes?

Tekton was designed to work natively on Kubernetes, and it incorporates Kubernetes best practices by default. On a related note, Jenkins X also uses Tekton to handle the execution and management of Jenkins X pipelines natively within Kubernetes.

Coverage of GitOps Workflow

Tekton is a complete solution, and depending on how you configure it, it will cover the entire GitOps CI/CD workflow – from integrating with a Git repository to deploying natively on Kubernetes.

Community, Maturity, and Popularity

There is a healthy community behind Tekton, and code commits are made to the project daily. It also has the support of some big names in the tech world, such as Cloudbees, Google, IBM, and Redhat, among others.

In terms of maturity, Tekton is slightly newer than Argo CD and Jenkins X. It’s still under development, and many features have not been added yet. The documentation could also use a bit of polishing here and there, but it will help you get the job done. Since Tekton enjoys widespread support and usage, it’s a viable project worth looking into if it fits your use case.

Setup, Operate, & Test GitOps Tooling for Free on Platform9

Setup, Operate, & Test GitOps Tooling for Free on Platform9

Jenkins X

Jenkins X is the cloud-native iteration of the traditional Jenkins CI/CD server. First announced in early 2018, Jenkins X was developed by Cloudbees, and it is now a project under the Continuous Delivery Foundation. Like the other projects discussed in this article, it was released under the Apache 2.0 license.

Jenkins X differs from Jenkins in that it was designed from the ground up to work for cloud-native applications using Kubernetes. Traditional Jenkins wasn’t designed to work natively with Kubernetes, and getting it to do so required implementing somewhat hacky solutions.

Jenkins X is considered to be “opinionated,” meaning that certain assumptions will be made about how things should be done in the interest of getting up and running quickly. This has the advantage of allowing developers or operations engineers to forego a steep learning curve in order to accomplish what they need without a lot of hassle. The disadvantage is that if you don’t like how Jenkins X does things, it will take more work to extend and customize it.

Some of the key high-level features of Jenkins X are:

  • Automated import of existing software projects
  • Automatic project type detection (i.e. Go, Java, Python, etc.)
  • Automatic pipeline creation including Jenkinsfiles and Dockerfiles
  • Automatic software environment creation (i.e. dev, staging, and prod)
  • Automatic Helm chart creation for deployments
  • Automated detection of changes in your repo and deployment to the appropriate software environment
  • CLI using the jx binary written in Go
  • Extensibility through the creation of plugins compatible with the jx binary

Deployment and Ease of Use

Depending on your use case, you may or may not already have a Kubernetes cluster available where you want to install Jenkins X. If you don’t, it’s recommended that you use Terraform modules to instantiate a new cluster. It’s also recommended that you run Jenkins X on its own cluster.

Once the cluster is ready, you will want to install the jx binary to your local machine. This is supported on Mac, Windows, and Linux, and depending on the installation method, it should only take a few commands.

You then install it to your Kubernetes cluster via jx boot.

In terms of ease of use, Jenkins X shouldn’t be a problem if you’re comfortable working from the CLI. There is also an Octant-based UI jx plugin that you can install.

Integrations and Configurability

In terms of Kubernetes integrations, Jenkins X is fully supported on GKE and EKS. AKS isn’t shown in the compatibility matrix, but the documentation shows that AKS installation of Jenkins X is possible. OpenShift is also supported.

As for repositories, Github is fully supported, but Bitbucket and Gitlab are currently listed in preview state.

Hashicorp Vault is supported for secrets storage.

As Jenkins X has an opinionated way of doing things, your mileage may vary in terms of configurability, depending on what you want to do. Under the hood, Jenkins X is a conglomeration of various Kubernetes-related projects, including Tekton, Prow, Helm, and others. It is also made up of various plugins that extend functionality from the basic CLI installation.

One thing worth mentioning is that the tried-and-true Jenkinsfiles are still used and supported, and they can also be edited if necessary. Depending on how well the automation serves your needs, you may not ever need to touch them.

How Tuned Is It for Kubernetes?

Jenkins X runs natively on Kubernetes, and in fact, it was designed for Kubernetes. You should check the compatibility matrix and documentation to ensure that both your version and your provider are supported.

Coverage of GitOps Workflow

Jenkins X provides an opinionated way of getting a full CI/CD workflow into place with a lower learning curve than other options. To one extent or another, it sacrifices some flexibility in order to make things easy to set up without having a ton of in-depth knowledge.

Jenkins X also has an opinionated way of covering the GitOps workflow. For example, a separate repository is created for each supported environment. This may or may not be acceptable, depending on how you want to structure your GitOps workflow.

Community, Maturity, and Popularity

Considering the scope of the project, Jenkins X has been progressing rapidly. There is still quite a bit of development going on, and the underlying projects that makeup Jenkins X under the hood are also in progress.

It doesn’t appear that Jenkins X is being utilized in as many companies’ production environments as Argo CD and Tekton, but that doesn’t mean it isn’t ready for production. Your best bet is to try it out for yourself and see if it meets your needs.

Conclusion

As you can see, evaluating tools for automating your own GitOps-based CI/CD workflow can be complex and challenging. It’s very important to keep your use case and your requirements in mind. You also need to make sure that you have adequate resources available for setting up and managing the solution you’re considering. Keep in mind that it will take time to evaluate, set up, configure, and test each solution. Last but certainly not least, you want to consider the learning curve involved with each solution as well as the in-house knowledge and skills available.

If you’d like to test one or more of these tools, Platform9 Managed Kubernetes is an excellent playground for setting up and operating GitOps tooling.

Steve Tidwell
Latest posts by Steve Tidwell (see all)

You may also enjoy

Why Managed Calico?

By Chris Jones

Multi-Cluster Kubernetes Deployments – When and Why?

By Chris Tozzi

The browser you are using is outdated. For the best experience please download or update your browser to one of the following: