Tekton Reviews

While working with the client at Deloitte, we focused on enhancing our DevOps practices and ensuring site availability through continuous integration and deployment (CI/CD) pipelines. Jenkins was the primary technology in use at that time. However, the client expressed interest in transitioning to cloud-native, more efficient solutions to create a futuristic platform. We chose Tekton due to its compatibility with Red Hat OpenShift, which was already part of the client's Red Hat subscription. Tekton's ease of customization and availability as a default plugin in Red Hat OpenShift made it the preferred choice for our project.

Tekton's most important feature is its cloud-native nature. Unlike Jenkins, which may not scale as efficiently, Tekton's CI pipeline can automatically scale up to handle increased workload demands without needing manual adjustments.

Another important aspect is the level of customization offered by Tekton. Each task in the CI pipeline can be customized independently, allowing developers to write code in various languages like shell scripting, Java, or Python and incorporate them into the pipeline as needed. This level of abstraction and customization greatly benefits developers in creating efficient CI pipelines.

Also, it can be challenging to understand the logs and troubleshoot issues without clear guidance. It's not always easy to reach technical support and get immediate answers. In my opinion, improvement in this area would be beneficial.

We use Tekton as a pipeline, specifically a CI/CD pipeline. We have created all these stages, such as build, deploy, and test, within Tekton in an OpenShift cluster. We use these technologies for all our development code. We have written our developing code in Java, Scala, and Tekton. 

Our workflow includes creating embedding vectors, detecting secrets in the GitHub repository, and more, all managed by Tekton stages.

Moving from Jenkins to Tekton has significantly reduced our costs. Previously, we were spending around $6,000 per day on our Jenkins pipeline for the same workload, whereas now we only spend around $1,000 dollars per day. This reduction is due to Tekton's cloud-native nature, which allows for efficient resource consumption and auto-scaling. By implementing Tekton, we have achieved a six times cost reduction.

I have been using Tekton for close to the last three years. The major reason is that I'm part of the IBM Cloud Kubernetes service, and most of my work is on Kubernetes. Tekton being Kubernetes native, was one of the reasons to adopt it. IBM is already doing a lot of work around Tekton.

Tekton has significantly helped us take the workload off Jenkins. This has directly impacted the cost of maintaining Jenkins. Tekton being lightweight means that the resource impression is much less compared to Jenkins when running inside Kubernetes clusters. If we were running 200 complex jobs or pipelines with Jenkins, we have been able to do the same in Tekton with a much smaller number of resources, almost half.

We are using Tekton for building some of our CI pipeline, continuous integration pipeline, as well as integrating some of our other pipelines, such as test pipelines.

In terms of cost savings, Tekton does not require licensing. If you have a Kubernetes or OpenShift environment, everything related to Tekton is free. Additionally, there are time-saving benefits as Tekton makes it easy to bring up pipelines quickly, which is particularly useful if the environment is lost.

We mostly use Tekton to run all of our pipelines. We create unit tests and also use it for Jira build messages as well as the Docker build application. We check the logs within Tekton itself and create a manifest to deploy in our development, test, and other environments.

We can create multiple pipelines with Tekton. I find it beneficial to show data from Tekton to another GitHub or Bitbucket pipeline.

We use the product to create and configure pipelines, manage continuous integration and continuous deployment (CI/CD) processes, and handle deployment activities for various environments such as development, staging, and production. It is instrumental in managing deployments in a microservice architecture.

The platform's most valuable feature is the ability to manage pipelines step-by-step. The 'promote' feature is beneficial as it simplifies deployment processes by allowing easy promotion of applications to different environments without needing to re-run CI/CD processes. 

I use the product primarily for CI/CD in application cloud-native environments. It helps us build code, and occasionally, it is also used for deployment.

The platform's most valuable feature is its cloud-native and Kubernetes-ready design.It integrates seamlessly with container environments, providing a significant advantage for Kubernetes users.

We don't know the customer's end goal, but we are developing a cloud-agnostic platform based on their wishes. That's why we moved almost all our architecture to Kubernetes. For our development pipeline, which is cloud-agnostic, we also put all our CI/CD pipelines on Kubernetes. We decided to use Tekton because it's Kubernetes-native for CI/CD. Currently, it works on Kubernetes in the GCP and Azure. So we use Azure Kubernetes Services and GCP.

The first functional requirement we wanted from Tekton or any other CI/CD pipeline was to be cloud-agnostic. We met this requirement with Tekton. One of our main goals was to improve the development experience. We wanted a narrow branch approach so developers could easily create isolated environments for feature branches. In this environment, it's good to have independent assets like the build system. For example, if a developer wants to develop and use microservices, they can create a feature branch, and Tekton and any build assets are isolated to this branch. Tekton allows this because it is a native Kubernetes build system and works with Kubernetes namespaces as an isolation strategy. You can isolate most Tekton assets in the Kubernetes namespace for your feature branch. This allows you to freely change Tekton assets and objects to adapt to your feature branch and requirements. Additionally, when you remove a namespace, all Tekton assets are removed with it, so you don't need to clean up build assets manually.