Tekton vs Jenkins: Head-to-head comparison

Continuous Integration (CI) has become a mainstay in the DevOps workflow of many organizations. It involves activities such as building, end-to-end testing, staging, and production environments and there is a variety of ready-made solutions we can use to implement CI.

Jenkins and Tekton are two of the most widely used CI tools, and we use them because they are dependable. While they’re both reliable, both fit some use cases better than the other one.

In this article, we will take a holistic approach to explain both tools, breaking them down into their fundamental components to give us a detailed understanding of how these two well-known CI tools differ and how their similarities and differences contribute towards a specific use case.

What is Tekton?

Tekton is an open-source framework for building continuous integration and delivery systems. By leveraging the Custom Resource Definitions (CRDs) in Kubernetes, Tekton uses the Kubernetes control plane to run pipeline tasks.

Tekton simplifies deployment across many cloud providers or hybrid settings. It is suited for developing, testing, and deploying containerized applications. The building units of Tekton are tasks and pipelines, which are based on YAML.

Pros

Tekton provides several benefits, notably its flexibility and cluster management components.

Configurability

Tekton is highly configurable. We can personalize reusable and shareable entities and even organize tasks in a pipeline in any order. This makes it easier to integrate custom features into Tekton.

We can also write our tasks and incorporate them into a pipeline if one doesn't exist. This is possible because task resources are container images and a list of commands. For instance, in the absence of the task for Java code, we could establish a container that contains the JDK and Maven. This flexibility has an advantage over other CI solutions because it offers us complete control over our application.

All-in-one CI tool

Efficient CI/CD requires adequate cluster management and fine-grained environment visibility. Tekton's modular dashboard offers these functionalities, although some further configuration is required. As a result, Tekton offers complete CI/CD GitOps cycle coverage.

Cloud Native

Tekton makes it easy to create cloud-native CI/CD pipelines due to its built-in best practices. This allows us to generate and distribute immutable images, manage infrastructure version control, or carry out simpler rollbacks. We can implement advanced deployment patterns with Tekton, including rolling, blue/green, canary deployment, and GitOps workflow.

Therefore, Tekton is very much tuned for Kubernetes and Openshift, making it a better choice if our applications and services are based on Kubernetes or Openshift.

Cons

The fact that pipeline settings are stored separately from code is Tekton's biggest drawback. We must manually apply Kubernetes manifests to modify the pipeline settings. This is particularly difficult since first, we have to insert the desired container image with a command line tool into the YAML file, deploy this image as a task, and then manually commit these to the manifest repo.

Additionally, Tekton is a little hard to manage and configure because we deploy many custom resource definitions (CRDs) to spin a functional pipeline.

What is Jenkins?

Jenkins automates software development, testing, and deployment. It is a Java-flavored continuous integration tool that contains a plugin hub with plugins used in any DevOps step or event. Even though it is a CI tool, it is also widely used for continuous delivery.

Jenkins has a "push" or "pull" formatted CLI or CI server. An event triggers the Jenkins CI. This event could take the form of an active code commit or a passive repository check by the CI server to see if the codebase has been modified.

Jenkins enables the usage of container technologies like Docker and Kubernetes for testing and packaging software releases and works with build tools like Maven and Gradle. Jenkins, however, is neither a native Kubernetes solution nor a native container CI solution.

Pros

Jenkins provides many benefits, most importantly:

Extensibility with plugins

To customize the functionality of a Jenkins system to meet organization- or user-specific demands, Jenkins provides a plugin hub with open-sourced plugins. On a Jenkins controller, we can add over a thousand plugins on a Jenkins controller to combine multiple build tools, cloud providers, analysis tools, and more. Jenkins also has extensive instructions for managing these plugins.

Support for hybrid and multi-cloud environments

Jenkins supports many hybrid and multi-cloud setups. It is reliable because it is built on Java, an enterprise programming language with a large ecosystem.

Cons

Jenkins has a few disadvantages that we look at below:

Complexity

Users often find it complicated to use Jenkins because it becomes challenging to navigate the 2000+ plugins. Also, the scripting language requires a substantial understanding of a JVM-based language, which may complicate things further.

Single-server architecture

Due to its single-server architecture, Jenkins only requires resources on a single computer, virtual machine, or container. Jenkins does not support server-to-server federation, which complicates the horizontal scaling of large-scale applications. Because of this, we cannot use Jenkins with more recent Java technologies like Spring Boot or GraalVM.

Resource intensive

The suggested hardware setup for a small team to run Jenkins is 1 GB+ of RAM and 50 GB+ of drive space, while resource utilization depends on the size of the team. Additionally, if running Jenkins as a Docker container, the minimum hardware requirements are 10GB of storage space and 256 MB of RAM. This greatly surpasses the resource use of other CI tools.

Tekton vs Jenkins: Head-to-head comparison

Let's take a look at how Tekton and Jenkins compare against each other:

Syntax

Jenkins is written using the Groovy syntax, a scripting language that shares similarities with Java. Tekton’s pipelines are declaratively written as YAML files.

Terminology

Let us consider the following basic terms in Jenkins:

1. Pipeline is used to automate the build, test, and deployment processes in Jenkins.

2. Node is any machine capable of executing a scripted pipeline.

3. Stage is a distinct subset of tasks performed in a pipeline.

4. Step specifies the exact action to be taken by the command or script.

For Tekton, let us consider the following:

1. Pipeline is a set of tasks.

2. Task is a sequence of steps as commands or scripts. Each Tekton task must have an apiVersion, the kind, metadata, spec, and steps. For example, let us consider this Tekton deploy task:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myprojectd-deploy
spec:
  workspaces:
  - name: source
steps:
  - image: my-deploy-image
    command: ["make deploy"]
    workingDir: $(workspaces.source.path)

• PipelineRun specifies the execution of a pipeline with one or more tasks.

• TaskRun specifies the execution of a task with one or more steps

• Workspace stores inputs, outputs, and build artifacts. We can also use it as mount points for credentials and configurations held in config maps.

For better resource management, Tekton also provides several optional fields, such as params, where we can provide the parameters that will be utilized in task stages and which must have a name, description, and default value.

The table below offers a technically correct mapping of Tekton and Jenkins concepts:

Jenkins	Tekton
​Pipeline	Pipeline and PipelineRun
Stage	Task
Step	A step in a task

Pipeline anatomy

Although both solutions carry out their functions in a pipeline-like fashion, the pipelines differ in their building blocks and arrangements even when they are programmed for the same function.

A pipeline in Jenkins might be declarative or scripted. Take this declarative Jenkins pipeline for building, testing, and deploying as an illustration:

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'make'
           }
       }
       stage('Test'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml'
           }
       }
       stage('Deploy') {
           steps {
               sh 'make publish'
           }
       }
   }
}

Build, test, and deploy are the three tasks in a Tekton pipeline. A Tekton pipeline can be created by progressively combining these tasks which must have been declaratively stated using the YAML syntax. For building, testing, and deployment, a typical Tekton pipeline is as follows:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: myproject-pipeline
spec:
  workspaces:
  - name: shared-dir
  tasks:
  - name: build
    taskRef:
      name: myproject-build
    workspaces:
    - name: source
      workspace: shared-dir
  - name: test
    taskRef:
      name: myproject-test
    workspaces:
    - name: source
      workspace: shared-dir
  - name: deploy
    taskRef:
      name: myproject-deploy
    workspaces:
    - name: source
      workspace: shared-dir

Mode of extension

Jenkins and Tekton can be extended, but their approaches and modes of implementation vary. Jenkins uses plugins, and the plugin index includes open-sourced plugins:

We can extend Tekton in two ways:

1. Using a task from the Tekton hub. For example, the git-clone task below serves the same purpose as the git plugin in Jenkins:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 params:
   - name: repo_url
   - name: revision
 workspaces:
   - name: source
 tasks:
   - name: fetch-from-git
     taskRef:
       name: git-clone
     params:
       - name: url
         value: $(params.repo_url)
       - name: revision
         value: $(params.revision)
     workspaces:
     - name: output
       workspace: source

2. By creating custom tasks and scripts. Let us consider this custom script written for the maven test command:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: maven-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-maven-image
    command: ["mvn test"]
    workingDir: $(workspaces.source.path)

Execution model

A control node for Jenkins is used to launch each container staged in the pipeline. This control node coordinates tasks operating in other nodes and centralizes the pipeline execution. Given that it has a cloned code repository, build history, and artifacts, we can refer to the control node as a workspace. When a task is given to a different node, the generated artifacts and the cloned code are kept there, but the control node keeps track of the build history.

On the other hand, there is no centralized dependency for execution with Tekton because it is distributed and serverless. Every step is carried out as a container running in a pod. Kubernetes fully schedules each PipelineTask, which runs as a standalone Kubernetes Pod independent of other pipelines or pods. Because the Kubernetes scheduler oversees them, a failed pipeline cannot bring down another one.

Support

Both Tekton and Jenkins integrate well across providers including AKE, GKE, and EKS. They also support a wide range of languages and frameworks.

Conclusion

Jenkins and Tekton are similar in that they can be connected with the K8s environment, support a variety of frameworks and languages, perform comparable deployment and CI/CD functions, and are extendable. They also both support container-based applications.

Both tools have different features, configuration flexibility, modes of extension, and even the elements that make up their pipelines. Given these similarities and differences, Jenkins appears to be more suited for legacy enterprise setups because of its capacity to emulate well-known automation scripts and a broad range of dependability and automation use cases. On the other hand, because it is k-native and offers more control, Tekton is ideal for distributed yet cooperative teams to create microservices or even more conventional monolithic applications.