Tekton Reviews

Our primary use case is for cloud integration and cloud deployment. Tekton is a cloud-native tool that we utilize in Kubernetes and OpenShift. It helps us with code integrations and code deployment. We use it for automating various processes and integrating it with our DevOps environment.

Tekton has improved our performance by allowing us to define metrics and resource limits, enhancing the performance of our whole pipeline. The ability to customize tasks and use custom containers has also allowed us to tailor our workflows to our needs.

The customization is valuable. We can make a lot of customizations, and data sharing between tasks using workspaces is very convenient. Moreover, the flexibility and ease of use in creating and attaching new tasks make it very user-friendly. The Tekton UI and user interactions are very good.

Tekton could improve by adding better documentation. The documentation needs improvement to clarify supported features and required integrations. Additionally, while it is currently a cloud-native solution limited to Kubernetes, an option to run it locally on our own systems would be very useful. Security integrations and third-party integrations also need enhancement.

We have been using the Tekton solution for nearly two years.

Tekton is stable and performs well. However, it would benefit from adding new features quickly to stay relevant and helpful.

Tekton is highly scalable due to its cloud-native nature.

We have not escalated any queries to Tekton itself. Since Tekton comes as an integral part of Red Hat, we rely on existing documentation and haven't had any issues requiring direct technical support.

In the past, we used Jenkins for CI/CD. Each tool has its own use case and pros and cons, but Tekton's cloud-native capabilities and ease of deployment and maintenance make it a better fit for our needs.

The initial setup of Tekton is very straightforward. We install it as an operator in our cluster, making maintenance tasks like auto-upgrades and updates easier.

There is no specific cost related to resource optimization provided by Tekton. We need to manage the resource limits and requests ourselves to prevent resource exhaustion, especially when running on cloud platforms like AWS, Azure, or GCP.

I recommend Tekton to anyone closely interacting with Kubernetes. It is particularly useful for larger teams with complex application deployment requirements. However, for smaller teams or simpler use cases, it may not be necessary.

I'd rate the solution six out of ten.

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.

While Tekton is highly effective for Kubernetes-based setups, it might not suit users who require more control over bare-metal environments.

I have been using Tekton intermittently for the past four or five years.

The product is stable. I have not experienced any crashes, and it operates reliably as a Kubernetes controller.

I have used Jenkins and Concourse before. 

Tekton is designed specifically for Kubernetes, making it a natural fit for Kubernetes environments. 

The initial setup was quite straightforward. I recently reinstalled it with minimal effort, particularly using the Tekton operator on OpenShift. The process was smooth, and there were no major challenges encountered.

The pipeline resources are comprehensive and meet our CI/CD requirements. They help automate the deployment process efficiently, and I have not faced significant issues related to resource consumption.

The product is free and open-source. Some platforms may have additional costs for advanced features, but the core framework is free.

Tekton has been more than other solutions efficient as it reduces the need to maintain servers like Jenkins. 

Overall, I rate it 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.

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. 

The product's version update management process needs improvement. Synchronization issues with other tools or libraries, like OTEL and Datadog, have been noted. Automated handling of these updates would be beneficial, as manual updates can be cumbersome.

I have been using Tekton for more than two years.

There have been occasional system downtime issues. I rate the stability an eight out of ten. 

The solution scales effectively through its integration with Kubernetes and microservice architectures. I rate the scalability an eight out of ten. 

I have not contacted Tekton's support team directly, but we have engaged Google support when necessary. Our internal team handles initial issues and escalates to the community or support teams as needed.

Tekton is a powerful and flexible open-source tool for CI/CD pipelines. It is effective for building, testing, and deploying applications in cloud environments. Its open-source nature allows for extensive configuration and customization.

Overall, rate it a nine out of ten as a product. It stands out well compared to other solutions like Jenkins. 

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.

Generally, we are using Tekton for deployments instead of Jenkins. We create pipelines in Tekton for a number of services, each with different logs and requirements, especially in our DevOps practices. I have been using this Tekton pipeline for nearly six months.

The main benefits we have seen from using Tekton include saving time compared to Jenkins. The user interface is easier to use, and there are no plugins required for installation, unlike Jenkins. Time savings and ease of use are significant advantages.

Tekton has a user interface that facilitates time savings, making it more user-friendly than Jenkins. It is easier to handle and eliminates the need for plugin installations.

The user interface of Tekton could be improved. Sometimes, it takes more time during production deployments than expected.

I have been using the solution for nearly six months.

Tekton is stable, easy to use, and currently provides good stability.

Tekton is scalable, and most of our team members are using the Tekton pipeline.

As of now, I haven't asked for technical support. I would approach technical support if I encounter any problems.

Positive

Before Tekton, we used Jenkins. Tekton is better than Jenkins in terms of user interface and ease of integration without the need for plugins.

The initial setup took about one week, and there were some doubts on how to operate and execute deployments. But after learning about the tools, the setup was smooth, and everything was configured properly.

Four teams were involved in the deployment process: the ECS team, tenant ops team, DevOps team, and development team.

There are efficiency gains due to time savings in pipeline setup compared to Jenkins. This is a major point of efficiency for Tekton.

I would recommend Tekton to other users who are considering its implementation. It's better compared to Jenkins.

I'd rate the solution eight out of ten.

I use Tekton generally for CI purposes and automation APIs.

We have created a Helm template for Tekton, and we're currently working on scripts. This allows us to create pipelines on the fly, which has significantly streamlined our workflow.

I have full control over it, actually, in my team. Another thing is that Tekton is based on Kubernetes. In Kubernetes, we have the concept of cron jobs which run on a time-to-time basis. In Tekton, we have the concept called task or task runs. We can expose an API and use the trigger and trigger-binding concept, allowing us to trigger tasks whenever needed. This mechanism is very nice.

RBAC is really needed for Tekton. Also, if you have too many PVCs and don't clean them up, it may stop working due to the limited number of PVCs you can create in a cluster.

I have been using it for the past two years.

Tekton is a stable product. One issue we might run into is when there are too many PVCs that haven't been cleaned up. We have mitigated this by creating a CronJob that runs every midnight to clear those tasks.

Tekton is scalable if well-planned. However, it is not a plug-and-play solution for now. You need to write the tasks according to your business case, which might differ from team to team or service to service.

While setting up, I was initially active on their Slack channel where I was able to get help. They were responsive.

Neutral

We were using Jenkins before Tekton.

The initial setup was daunting and took me four months to set it up and get the flow. There is a steep learning curve, especially with concepts like event listeners, event triggers, and trigger binding.

Tekton was initially very daunting, and it took me a long time to get the flow. However, once you get it, it’s awesome.

I'd rate the solution six out of ten.

We use Tekton primarily as a CI/CD tool. We develop the product, and after developing the product, we deploy it to the cloud. Before deployment, Tekton is used as a CI/CD tool to validate and check our test cases, vulnerabilities, and licensing issues. If any test cases are written, they will first validate Tekton cases. Once the test cases pass, it moves on to check for vulnerabilities and licensing issues using Fosa, which is one of our QA and Check Point tools.

Tekton has significantly improved our organization, especially in the area of reusability. When we moved to Tekton from Jenkins, I felt that the tasks could be reused for any number of pipelines within the same cluster, which was not the case with Jenkins. This reusability is a major benefit. Moreover, it has streamlined our CI/CD pipelines, making the deployment process much more efficient. Tekton provides a clean UI interface and allows us to run multiple tasks simultaneously, which has enhanced our efficiency and productivity.

The most valuable features of Tekton include the reusability of tasks, the clean UI interface, and the binding of services and secrets. The tasks can be reused for multiple pipelines, making it very efficient. The UI interface appears very clean and user-friendly. The binding of services and secrets is also very clear and well-organized.

One area where Tekton can improve is log management. Currently, logs are often deleted after a day, making it challenging to refer back to logs from previous pipelines. It would be beneficial to have access to logs for at least the past two or three days. 

Additionally, stability needs to be improved. Sometimes Tekton crashes or freezes during important deployments, and this can cause delays. Enhancing stability and log management would greatly benefit users.

I have been using Tekton for almost three years, approximately from the time our organization migrated from Jenkins to Tekton.

The stability of Tekton needs improvement. Occasionally, Tekton crashes or freezes during important deployments, which requires waiting and troubleshooting. This instability can be problematic, especially during critical launches.

Tekton's scalability is generally good, but there is room for improvement. The resource quotas are somewhat limited, and increasing the resource quotas could enhance scalability further. The ability to run pipelines in parallel is a good feature, but expanding the resources would improve scalability even more.

Our organization has sufficient technical support for Tekton. However, there are times when more support would be beneficial, especially when dealing with production launches and critical deployments.

Neutral

Before Tekton, we used Jenkins. Our organization decided to switch due to the cost, performance, and the ability to leverage new tools and applications.

The initial setup of Tekton was somewhat challenging. It took a while to understand the various components, such as service binding, role binding, and how to create routes and bind services. It was a bit difficult at first because I was the first person in my team to explore Tekton, but after gaining an understanding, it became much easier.

The deployment and implementation were handled within our organization. A few team members, including myself, explored the functionalities and shared our knowledge with the rest of the teams.

The return on investment from Tekton is primarily seen in time savings. Once the initial setup is complete, the automated processes reduce the time needed for deployments and streamline the workflow.

I'd rate the solution seven out of ten.

In my company, we use Tekton for the pipeline, specifically Bitbucket pipelines. We have some cluster setups as well. In order to run some testing of the cluster, we chose to handle pipelines via Tekton.

The best feature of Tekton is that it is a Kubernetes-native tool for CI/CD. The tool offers flexibility and compatibility. If we look under the Kubernetes-native area, Tekton is built to run natively on Kubernetes, so it leverages Kubernetes 'scalability, security, and robustness, making it an ideal cloud-native application. I can relate to the pipeline customization in Tekton. It provides a highly customizable and reusable pipeline component. You can define tasks and pipelines that suit your specific workflow needs and easily reuse them as a different service platform. If you see the interoperability, Tekton is designed to indicate that there are other tools and services in the Kubernetes ecosystem. It makes it easy to incorporate things into the existing workflow.

Earlier, I used to use Jenkins pipeline, but compared to Jenkins, Tekton is better. Tekton is quite a user-friendly tool. The tool offers good dashboard access, and it is extremely user-friendly. If you are a beginner, then accessing the flexibility part can be overwhelming. We think the learning curve of the tool is steep, especially for those who are not already familiar with Kubernetes. There is a need to improve the recommendations and create more tutorials for the tool. The tool is very user-friendly for advanced users and not for beginners. There are some limitations, especially since the tool primarily operates through YAML configurations and command lines with limited graphical user interface options. While there are some third-party tools that look like Tekton's dashboard, there are still basic and compact major systems like Jenkins or GitLab.With more advanced built-in CGI and GUI, as a user, we can make it easier to monitor and manage Python faster. We can also improve the data handling and debugging. The debugging of failed pipelines in Tekton can be challenging. The error messages are not very descriptive, and the tool has limited support for step-by-step debugging. So, the improvement in error handling and data handling for debugging needs to be improved so that it could significantly improve the developer experience.

I have been using Tekton for three years. In our company, we have been using the tool for more than eight months. I am just a user of the tool.

In our company, there are around more than 5,000 employees. There are actually many things under the cloud and platform delivery and infrastructure. We don't know the exact number of employees who are using the tool. I believe over 100 people in my company use the tool.

In my entire career, I never went to the support team for help. If I had any doubts or any kind of features, I was able to Google it or use ChatGPT.

The solution is deployed on the cloud.

Beginners should go through the product documentation. There are many tutorials available on the product that can help a person to configure the pipeline and task functions. Once you get a proper idea of the architecture of Tekton and how it works, only after knowing how to use the tool will a person get to apply the practical knowledge in the Tekton tools. I suggest that businesses get an idea about Python and how it works, as they need to understand the architecture of Tekton.

I rate the tool an eight 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.