Tekton Reviews

I installed Tekton as an operator in OpenShift. Tekton is a pipeline tool. It operates within OpenShift, which is similar to how Kubernetes resources are managed. With Tekton, we utilize CRDs to define pipelines. Using the Tekton dashboard, we can create CI integrations for our applications. For instance, I used Tekton to manage CI for a Cloud-based Java application and an ongoing frontend application. Tekton's form-based approach is convenient for declaring variables and commands, handling secrets, and authentication. Overall, Tekton's ease of use and competitiveness compared to tools like Jenkins or GitHub Actions made it the preferred choice.

I use Tekton for pipelines in its original form, leveraging all the information and documentation available.

Tekton boasts multiple integrated features, making it a versatile tool. Tekton simplifies tasks by providing a beautiful interface and clear interactions. It seamlessly integrates with GitHub, enabling direct interaction. It is convenient to declare comments and variables within the same interface, eliminating the need to search for them before executing commands. In essence, Tekton functions as a comprehensive dashboard, encompassing all necessary features.

The deployment could be more accessible.

I have been using Tekton as a partner for one year and two months.

I rate the solution’s stability a nine to ten out of ten.

The documentation is very good.

The first time I connected to Docker Hub through Tekton, I encountered an issue with authentication parameters. Initially, I couldn't find where to declare the authentication credentials. These files had to be declared as a config map in OpenShift. Once configured, this config map had to be used as a parameter with Tekton. Although I spent some time searching for this information, eventually, It became straightforward, especially after using it in multiple projects.

Tekton was installed with OneClick. It's very fast to install this operator on OpenShift. It takes about fifty seconds to deploy entirely

Tekton integrates seamlessly with GitHub, creating three distinct environments: pre-production, development, and testing. Each environment is efficiently managed using Spectrum. It maintains its variables and comments before launching pipelines in any environment, ensuring clear separation. Installing it on OpenShift is considered one of the most valuable tools for DevOps engineers, providing a comprehensive view of the application.

Tekton was utilized within OpenShift and deployed on an on-premise server. We employed Argo CD for deployment. Kubernetes manifests were authorized and stored in GitHub. Tekton is tailored for the GitOps approach and is recommended to be integrated directly with GitHub repositories. With Tekton, CI pipelines were initiated. After completing the CI process, an image was generated and stored in GitHub. Subsequently, this image was utilized by Argo CD as a container for deployment, and OpenShift deployed it using Kubernetes manifests.

I recommend Tekton to my friends who work on a per-shift basis instead of Jenkins because, with Tekton, you don't need to install plugins or configure them. All the necessary plugins are already installed in the base image of the tool you want to use. You must install that base image, which is readily available in the developer hub or from another image provider. 

Tekton is easy to use in the pharmaceutical industry. This ease of use stems from its versatility in supporting two main types of workflows: working with AML files or utilizing forms with cases to manage and specify parameters and comments.

We are an organization focused on automating infrastructure and creating CI/CD pipelines for application development.

My advice is to leave it for open source rather than having the technical enterprise handle it, allowing students and universities to engage with it. As an instructor, It is advantageous for them to learn and adopt Tekton because it's relatively easy compared to Jenkins. Many students and Jenkins users struggle to learn about CI/CD and default pipelines, so I strongly recommend using Tekton.

Overall, I rate the solution a nine out of ten.

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.

The most beneficial aspect of Tekton is its compatibility with containerized applications. Since I am skilled in Docker, Kubernetes, and OpenShift, Tekton aligns well with these technologies. Unlike Jenkins, which requires an external node, Tekton eliminates that need. 

The installation process is seamless, requiring fewer resources compared to Jenkins. Tekton supports CLI and graphical user interfaces, is Kubernetes-native, and is particularly suited for event-driven cases. Each component is managed as code in YAML, making it easy to maintain and set up pipelines in different infrastructures.

Tekton lacks integration capabilities compared to other CI/CD tools like Jenkins and Travis. For instance, Jenkins offers plugins that facilitate easy integration with other software delivery tools. 

Tekton needs to improve its endpoint communication routes for better integration. Another area for improvement is security management. 

Jenkins offers RBAC for user access management, which Tekton lacks. Additionally, Tekton currently has no backup mechanism for execution logs, which puts run-related data at risk of loss.

I have been working with Tekton, along with Argo, for the last four years.

Tekton is stable. I have never encountered scenarios where Tekton-based components were in a degraded state or not working.

I have not worked on Tekton from a scalability perspective so I cannot comment on its scalability.

I raised a feature request for parallel execution at the step level in the official Tekton forum but did not receive a solution. Technically, the support was skilled, and I would rate them a seven out of ten. However, from the perspective of the solutions provided, I was not satisfied.

Neutral

In our discussions, we frequently compared Tekton with Jenkins due to Jenkins' widespread use and its robust plugin ecosystem.

Initially, we deployed Tekton using the required YAML files. Currently, we deploy using the operator, making the process about 70% easier with some issues.

I deployed Tekton individually. Not many people were involved in the process.

Tekton does not require licensing fees. If there is a Kubernetes or OpenShift environment, everything related to Tekton is free. This results in significant cost savings compared to licensed tools like Jenkins, Travis, or Bamboo.

We compared Tekton with Jenkins and Travis, noting that Jenkins and Travis have better integration features but Tekton offers advantages in resource requirements and ease of deployment.

I recommend Tekton for CI/CD pipelines due to its event-driven capabilities and Kubernetes-native approach. The setup, maintenance, and cost benefits are significant. Tekton's approach to managing pipelines as code ensures that you can easily recreate and maintain your pipelines across any supported infrastructure.

I'd rate the solution six out of ten.

When we migrated to Tekton, IBM Continuous Delivery provided pipelines, which you can run on Tekton. Tekton provides a feature where you can schedule the job. You can just go and create schedule triggers. Since part of our services has to go through audit, compliance, and monitoring, we had to run multiple operational tasks in our day-to-day job. These tasks included monitoring our database backup and scanning the servers or applications we were running.

We have to scan the Docker images we run on IKS and OpenShift clusters to ensure the running server doesn't contain any CVEs. We have jobs in place to scan those images. We need to track all this as part of our automation jobs. We have a small team of two to three members, and we have come up with a lot of automation tools. We started running all this using Tekton pipelines, which has been greatly helpful for us. It has become very productive and saved a lot of time for our team and many other teams.

We started generalizing our tools and sharing them with others. All the cloud services have been using it because they have to go through the same audit, same compliance, and same monitoring use cases. Instead of them coming up with their own automation, we have come up with a common toolchain.

We created the template and shared it with the cloud service team. They started using it, which saved resources and time for multiple things. Last year, that was a major achievement. Tekton has been very useful in scheduling data. We don't need to worry about getting reports, collecting evidence, or monitoring everything because they are being done perfectly.

As part of our CI/CD, anything we do today runs on a Tekton pipeline. If we are doing continuous integration and deployment, we run it on a Tekton pipeline. Since we have been using different languages like Java, Go, Node.js, and React.js in our development work, we have to integrate security checks. From day one, we have to integrate security into our development.

As part of continuous integration, we have started adding those tasks. That has beautifully worked for us. All the security checks as part of continuous integration or delivery ensure that we are not deploying any vulnerable images, vulnerabilities, or CVE packages in our production server. We are adding all those security checks as part of our CICD. We can add small checks as part of Go or run a Go scan. That was one good thing that was helpful for our team and many other teams.

I'm part of one of the open-source projects. When any event occurs, I want the pipeline to run by itself. If a security event is triggered, the pipeline should detect and automatically remediate it, which does not currently happen.

Tekton should include many features to integrate event-driven pipelines. For example, when GitOps triggers an event, you have to trigger a pipeline. Such event-driven things could be improved.

I have been using Tekton for four years.

Tekton is a stable product. You can run your pipeline on your own machine. I don't want to run this pipeline in a managed worker or somewhere where other services are maintained. I can have my own private worker and run the pipeline there. The machine on which I'm running Tekton could be a compliant machine.

I rate the solution’s stability a nine out of ten.

Tekton is a scalable solution.

I rate the solution’s scalability an eight out of ten.

We used to run all of our operational jobs using Jenkins jobs. We had set up virtual machines to run the Jenkins server, and it used to go in a queue and take a lot of time. As all cloud services were using the same server, it was getting into a queue and taking time to deploy. We were facing a lot of issues, and it was affecting our productivity. Then, we decided to migrate to Tekton.

The continuous delivery team internally integrating Tekton might face challenges, but we haven't faced any challenges implementing the tool.

I would highly recommend Tekton to other users because it's faster and more productive. For example, all our IBM Cloud Services initially used Jenkins as a pipeline for all the operational and compliance-related work. Now, everybody is migrating to Tekton and using it.

Overall, I rate the solution a nine out of ten.

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.

Based on the event triggers, we found a workaround proposed by the Tekton team. This involves trigger groups. However, I'm a bit worried about scaling Tekton from the point of view of big CI/CD processes. As you know, Tekton uses a Kubernetes native approach with a controller feature. The controller is a service that controls every aspect of Tekton's work in the cluster. The problem is that this controller works in a single zone. You can configure the number of replicas for this controller for high availability, but the controller doesn't allow a sharding strategy. For example, you can't set up the controller to process only a subset of the Tekton objects in your cluster. This singleton approach could lead to performance problems in the future. Currently, our production controller takes around 500 megabytes of RAM. If our environment grows, it might take one or two gigabytes. It would be better to have a sharding or partition strategy to distribute the load from the single controller to multiple ones.

I have been using Tekton for the past six months actively, but extensively I started exploring it two months ago.

Tekton is convenient because, previously, I had experience with GCP Cloud Builds. The good thing about Tekton is that it works well with autoscale in Kubernetes. You can set up zero nodes, and when you run your Tekton CI/CD pipeline, the number of nodes will grow automatically. This allows for cost efficiency from a build point of view because you won't need to have pre-existing nodes for your workloads.

My organization is promising to move all our builds to Tekton. Of course, we have some concerns about scalability, but for now, it works okay.

We found the solutions faster than the technical team answered us. They have a standard GitHub community forum or issues list where you can ask questions and create issues. But I think their response is not so fast. It took around maybe one week to get an answer from them. But, of course, it's understandable because this is open source and not a paid project for them. 

The process of installation has worked smoothly. You just run a couple of commands, and Tekton is installed in your Kubernetes cluster. There are no problems here at all. We did meet some issues with the default configuration of Tekton because, by default, Tekton uses the Affinity feature, some kind of PostgreSQL feature. This feature, when enabled, prevented better scaling. We turned it off, and everything worked as we expected. By default, this feature is turned on, and we met some scalability issues. This feature allows assigning different pods for the same pipeline to the same node. But if you set up different requests and limits for different stages of your pipeline, assigning them to the same node prevents scaling up the node pool. That's why we turned this feature off. Now everything works okay. So maybe the default configuration of Tekton is not perfect, at least for our scenario.

Initially, our project was located in the GCP, but our customer wanted to make it cloud-agnostic. They wanted to move it to Azure and maybe on-premises afterwards.

Based on our requirements, the main need was for a cloud-agnostic platform, which is why we chose to run everything in Kubernetes, and Tekton fits this task easily. If you're familiar with other CI/CD pipelines like GitHub Actions or GitLab CI and they meet all your requirements, it might be good to stick with them. They are quite similar in functionality. Tekton stands out because it provides supply chain security out of the box with Tekton Chains, which we use. It includes built-in tools to sign and verify images. GitHub Actions and GitLab CI don't have this feature out of the box, so you'd need to implement it yourself. For better security, Tekton might be a better fit.

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.

Tekton is a cloud-native solution. It offers optimal resource consumption, allowing tasks to be run more efficiently and at a lower cost. Tekton pipeline resources can be triggered automatically by GitHub through webhooks. With Tekton, tasks like build, test, deploy, and vulnerability scanning are streamlined. 

Additionally, custom tasks offer the ability to integrate notifications to the building team via Slack or email, and the pipeline will only start after approval, enhancing the efficiency of deployment processes.

One area for improvement is the number of CRDs created during installation. Tekton currently creates 10 to 11CRDs, which can be overwhelming. Instead, it would be better to have just one CRD that can handle all the information and create other necessary components automatically. 

Additionally, more integration capabilities for security, such as DAST, SAST, and IAST, should be directly built into Tekton to facilitate easier implementation of security features.

I have been working with Tekton for almost four years.

In OpenShift clusters, we have encountered issues related to memory and CPU usage, and webhook configurations not triggering as expected. This has sometimes resulted in redundant pipelines running simultaneously for the same feature branch. We resolved this by creating our own customized operator to ensure only the latest pipeline runs.

We found Tekton to be scalable. We manage this by configuring CPU and memory limits for each task, allowing tasks to start with minimal resources and scale up as needed, ensuring optimal resource utilization.

We have not directly escalated issues to the Tekton technical support team. Instead, we address issues by creating our own customization operators to resolve them internally.

We previously used Jenkins. While Jenkins required writing in Groovy script and developers needed to be familiar with Jenkins files, Tekton simplifies this process by automatically handling tasks based on cluster definitions.

The initial setup in an OpenShift cluster is user-friendly, taking around five to ten minutes to configure. For Kubernetes, it might take fifteen to twenty minutes. 

One area that could be improved is reducing the number of CRDs created during installation from around twenty to thirty to just one CRD to streamline the setup process.

We implemented Tekton with our own internal team. We configured timeouts, SSL certificates for webhooks, and resource limits to ensure efficient operation.

Shifting to Tekton from Jenkins has considerably reduced our costs, with savings from six thousand dollars per day to approximately one thousand dollars per day. This sixfold reduction is due to Tekton's efficient cloud-native features and resource optimization.

I would recommend Tekton for creating CI/CD pipelines due to its ease of learning, adaptation, and cloud-native features. Tekton allows for the creation of cluster tasks without requiring developers to write complex configuration files, unlike Jenkins.

I'd rate the solution eight out of ten.

We are consolidating everything in Kubernetes. We are looking for a cloud-native CI/CD solution and came across Tekton as one of the options. We are using Tekton in parallel with ArgoCD. The CI part is done by Tekton with multiple steps supported by Tekton extensions, including Git clone and build steps.

It is ease of use for us. We have found Tekton to be very scalable in Kubernetes, running multiple jobs seamlessly without an issue. It is also easier to use once you get it rolling.

The ability to scale is valuable. Tekton scales up or down within Kubernetes without an issue, making it easier to use. Tekton is very efficient at handling multiple jobs.

Improvement is needed in the build step. Tekton currently supports Kaniko, but an official Docker builder would be beneficial to reduce build times. The extensions should also be improved. 

Additionally, the current extensions for Tekton could benefit from development. Moreover, it would be helpful if it included an out-of-the-box graphical interface, as we need to install it as an extension.

It might be two to two and a half years, maybe.

Tekton is running on our own infrastructure. Stability relies on the quality of our infrastructure; there are no issues with Tekton itself.

Tekton is scalable within Kubernetes, managing multiple jobs seamlessly.

The Slack community is good and helpful. We have received support by posting issues in the community.

Neutral

We have used multiple solutions, including GitHub Actions, Argo Workflows with ArgoCD, and Bitbucket pipelines. Currently, we are using GitHub Actions along with Tekton.

The initial setup of Tekton involves installing it, which is easy with a few commands. However, defining and writing pipelines can be complex and requires practice.

Tekton is handled by the DevOps team, which consists of five members.

We have previously evaluated GitHub Actions, Argo Workflows with ArgoCD, Bitbucket pipelines, and multiple other solutions.

If you want to consolidate everything with Kubernetes, Tekton is a better option as it is part of the main tech stack comprising Kubernetes.

I'd rate the solution seven out of ten.

At our company, we use Tekton for the deployment pipeline, and it's also implemented in the Kubernetes cluster. Tekton manages the CI/CD pipeline processes. 

The flexibility of Tekton is the most valuable feature. Multiple pipelines can be built using Tekton, and the solution acts as an operating system for the CI/CD operations. 

Tekton lacks sufficient documentation, which makes it quite difficult for startups to handle the product. 

I have been using Tekton for one and a half years. 

In our organization, we have faced some issues with the stability of the solution. It's unclear to our company team that how the product handles the APIs, because resources are available for Tekton with varying API versions. The aforementioned fact creates confusion about which API version to use in Tekton which can be solved only by thorough reading of the documentation. But at our company, we haven't faced any bugs in the solution. 

It's a scalable product. There are about five Tekton users in our organization. 

Our organization's issues with the solution were solved using the documentation and the GitHub repository. 

At our company, we are planning to switch to a simpler solution than Tekton due to its lack of documentation and simplicity. 

At our company, we are able to install Tekton seamlessly without any issues. 

At our company, we used the open-source version of Tekton to manage the infrastructure. 

The main trouble with Tekton is that you need to understand the native concepts and the instructions that can be used to manage the pipeline. I would advise others to use Tekton only for complex deployment processes and also if there is a need to integrate the CI/CD software within the Kubernetes cluster for cost-effective reasons, otherwise simpler solutions like GitHub Actions can be used.

Everyone should gain sufficient knowledge and training on Tekton before using the product. Once a team has adopted Tekton, switching to another product can be difficult. 

Tekton allows integration to make the deployment process smoother. In our company, Tekton is implemented within the cluster and thus actions like AWS resource modifications, addition of images to the container registry and permission updates can be carried out to improve organizational capabilities and efficiency in deploying applications. 

A beginner with a proper understanding of Tekton documentation, implementation and knowledge of CI/CD processes will probably not face any difficulty with the product. I would overall rate Tekton a seven out of ten. It's a high-end solution and if a user has enough time and resources, then Tekton can be used to solve every issue regarding deployment processes. Organizations with small teams should rather choose an easier solution than Tekton. 

The platform's most valuable feature is its wireless capability, which makes installation easy and sets up the flow.

The product's UI could be improved, as there are occasional latency issues. The triggering part, especially the CRD installation needs enhancement.

I have been using Tekton for one and a half years. 

The platform could be more scalable. 

The technical community support could be better.

Neutral

The initial setup process is easy. 

The product is free of cost.

We used Tekton to integrate it with different DevOps tools. We used various SaaS tools like Fortify and Jenkins and security tools such as JMeter and Google Lighthouse. 

I rate it a seven out of ten.