Jenkins vs JenkinsX vs Tekton

Jenkins is probably one of the most popular tools for implementing DevOps lifecycle. Kubernetes, on the other hand, is also proven to be the best choice for container orchestration. We always seek ways to minimize compute time for production and other environments to reduce costs including operational costs. When we combine Jenkins + Kubernetes it’s easily achievable. Let’s see how we can achieve this goal.

What is Jenkins?

Jenkins is one of the most popular tools in today’s market, built for Continuous Integration purposes but also heavily used for Continuous Deployment/Delivery. It’s mainly used to automate build, test and deploy solutions in various environments. Written in Java, and supported other features with plugin approach. It has plugin available for every possible scenario in the realm of DevOps lifecycle.

What is JenkinsX?

James Strachan, the Chief architect of Jenkins X defines it as an open-source opinionated way to do continuous delivery with Kubernetes, natively, without worrying too much about the underlying infrastructure. It is an extension or a sub-project of Jenkins and is supported by popular cloud platforms like Amazon, Azure, Google Cloud, IBM Cloud, OpenShift and Pivotal. Jenkins X uses the best practices of DevOps to provide the developers with an increase in speed and reduce production time.

What is Tekton?

Tekton is a cloud-native open-source framework that enables developers to build, test, and deploy inside a Kubernetes environment using continuous integration (CI) and continuous delivery (CD) pipelines across multiple cloud providers or on-premises systems by abstracting away the underlying implementation details.

What is the need for Jenkins alternatives?

The way software is developed has evolved and transformed in the last few years. DevOps are gaining highest priority in the industry.

Industry goals are now:

• Faster time to market
• Reduce downtime, increase small incremental deployments (Amazon is doing more than thousand deployments hourly)
• Bring agility and reliability to the product development and delivery

These goals are the backbone of DevOps with other evolving development models and approaches.

Like:

• Microservices has become a de facto development model for new products. Even existing products are transforming into microservices.
• Container eco-system is growing hand-on-hand with microservices.
• Container orchestration platforms and services like Kubernetes, etc. and managed services provided by each cloud vendor like GKE, AKS, EKS, etc.

With all these evolutions, there are better options available to gain advantages of scale, pay-as-you-go model offered by all cloud vendors and dynamic nature of DevOps lifecycle. JenkinsX and Tekton are the two results to materialize these advantages.

Jenkins vs JenkinsX vs Tekton

We have already seen how we can deploy Jenkins on Kubernetes cluster in this article.

By deploying Jenkins on the Kubernetes cluster, we can take advantages like:

• Ephemeral build executors – only use compute power when the pipeline is running
• Supports multiple operating systems
• Speed with less cost – ephemeral build executors launch in seconds
• Less carbon footprint – the less you use compute power the less carbon footprint

But Jenkins requires lots of configuration and plugins in order to work inside Kubernetes. The JenkinsX is just simplifying this complexity of configuration. Tekton takes CI/CD to the next level by re-structuring the pipeline-as-code.

Jenkins vs JenkinsX

• Configuration
  • Jenkins requires additional plugins and configuration to work in Kubernetes
  • JenkinsX simplifies configuration and setup
• Adaptation
  • Jenkins adapts the process according to the requirements
  • JenkinsX defines the process
• Configuration Approach
  • Jenkins uses GUI first approach for most of the configuration
  • JenkinsX uses CLI/API first approach and Configuration as Code approach for most of the configuration parts
• GitOps
  • Jenkins configuration doesn’t support GitOps (not Git driven)
  • JenkinsX supports GitOps, all the configuration driven by Git repository
• Preview Environments
  • In Jenkins you can create preview environments manually
  • JenkinsX creates preview environments automatically for each pull request, so we can see the effect of changes before merging them
• Naive Comparison
  • Jenkins is a blank slate for CI/CD
  • JenkinsX is pre-configured, ready-to-go toolkit for CI/CD
• Flexibility
  • Jenkins is more flexible compared to JenkinsX, you can use Jenkins for a broader range of tasks such as integrating disparate tools, etc.
  • JenkinsX is less flexible, so less extensible in a way or less customizable in usage perspective because it’s built for specific goal/usecase in mind

Use cases for JenkinsX

JenkinsX is a preferable option for two key use cases:

• Kubernetes implementation
  • JenkinsX provides default configuration and environments to run applications quickly on Kubernetes, while Jenkins requires extensive configuration and also involves considerable amount of time to learn and use all the plugins to make it happen
• Need support of multiple DevOps environments
  • JenkinsX supports multiple DevOps environments model as Configuration as Code (GitOps) via Kubernetes Namespaces out of the box, while using Jenkins it takes lots of manual efforts, scripts, etc. to achieve the same thing

Where does Tekton fit in?

Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems.

In essence, it’s a framework that defines the pipeline. Consider it as a pipeline execution engine. It can be clubbed with:

• Jenkins using plugins like Tekton client
  • Easily reuse Tekton and Jenkins X from Jenkins
  • This way you can use Jenkinsfile (the usual way in Jenkins to define the pipeline) to define Tekton pipelines
• JenkinsX has Tekton as its pipeline execution engine by default

Jenkins vs Tekton

• Runs
  • Jenkins runs on Servers/VMs/Kubernetes
  • Tekton runs on Kubernetes
• Scripting
  • Jenkins supports loose scripting or pipeline way to define the tasks
  • Tekton is object oriented, everything is defined in an object-oriented pipeline, tasks, etc.
• Languages
  • Jenkins supports multiple languages via plugins
  • Tekton has built-in support for multiple languages
• Structured
  • Jenkins has Jenkinsfile which can keep your entire pipeline, otherwise you need to wire-up build, test, deploy, etc. pipelines via triggers
  • In Tekton files are properly structured
• Workspace
  • Jenkins storage is in a workspace directory
  • Tekton storage is a workspace pvc

Jenkins pipeline vs Tekton pipeline

The building blocks of Jenkins and Tekton are not equivalent, and a comparison does not provide a technically accurate mapping.

Migrating sample pipeline from Jenkins to Tekton

Jenkinsfile:

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

Tekton build.yaml:

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

Tekton test.yaml:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make check"]
    workingDir: $(workspaces.source.path)
  - image: junit-report-image
    script: |
      #!/usr/bin/env bash
      junit-report reports/**/*.xml
    workingDir: $(workspaces.source.path)

Tekton deploy.yaml:

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)

You can also combine all three tasks in the single yaml file.

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

References

• What is Jenkins X? | Jenkins X
• How it works | Jenkins X
• Tekton
• Welcome to Tekton | Tekton
• Concepts | Tekton
• Easily reuse Tekton and Jenkins X from Jenkins
• Jenkins X ❤ Tekton | Jenkins X