Tekton Reviews

I am a PHP developer, and I create software for my clients. In the IBM cloud, I manage all my source code by GitLab. Every project I develop is ultimately deployed into a container on Kubernetes. Toolchains on IBM Cloud manage all the steps to deploy my projects, and all of these toolchains are made with Tekton.

One of the best things I appreciate is that Tekton runs on the Kubernetes platform. This is very useful when working on a project with other team members. For instance, suppose we have a very big project that requires building a large amount of source code or running many unit tests. During the build and unit test phases, Tekton on Kubernetes allows us to have a scalable machine to handle these tasks. This scalability is the most useful aspect for me.

On the other hand, if you have a simple project but many programmers continuously commit code, having a scalable machine to manage the entire toolchain is also very beneficial. The tool is easy to understand and comes with documentation. 

One feature I appreciate in Tekton is the ability to segment your toolchain into different tasks. For example, before building my source code, I can personalize a task to check the syntax with tools like Linter. Additionally, before running unit tests, I can check for updates to an SQL database or generate documentation using Javadoc style. Personalizing each task and segmenting the toolchain is extremely useful for me.

The tool should improve in terms of output flexibility. It runs on a specific Kubernetes machine, and the persistent memory storage is on a single partition. Improving this aspect could make analyzing logs and toolchain outputs from external tools easier.

I have been using the product for a couple of years. 

In my specific case, when I started a couple of years ago, I experienced some problems in the toolchain. When some steps of the toolchain failed, the errors were not correctly managed. However, after a couple of months, all the features became stable and efficient. I'm very satisfied now.

The solution is scalable because it runs on the Kubernetes platform. My company has three users. 

I have only contacted IBM Cloud support and not Tekton's. 

I used Jenkins before Tekton. 

Setting up Tekton in the IBM cloud environment is easy. It's very useful and straightforward. I tried using it in a different environment, and I must admit that while there is good documentation, you need a strong base of skills in Linux and other areas because Tekton uses several tools with Python, Java, etc. It's not too easy, but it's not too difficult either.

The solution is open-source. 

I chose IBM Cloud because my first experience with it was very positive. IBM Cloud allows you to choose a target deployment platform, a container you can scale and configure with resources. It’s extremely easy to create a toolchain, starting with your Git project and automatically deploying it on this application container every time without configuring the environment.

Before using Tekton, you should evaluate several aspects of your project: its size, the frequency of commits, and the target of your deployment. From a technical perspective, you need basic skills with the Linux command line and a minimum understanding of Kubernetes.

I rate the overall product a ten 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.

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 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.

Tekton is used as a Kubernetes native tool for creating CI/CD pipelines. It is used for creating multiple tasks that can run as pipeline runs for several services. This helps in reducing time wastage and has several benefits. I work mostly on creating tasks and pipelines while my colleague handles the initial setup and login.

Tekton is beneficial for our CI/CD processes by enabling multiple task runs, which means we can use the same task for multiple services or deployments, saving time. It scales automatically based on the number of tasks or pipelines running, which is efficient and effective for our development needs.

One valuable feature is the ability to create multiple tasks and reuse them for several task runs as pipeline runs. Another advantageous feature is its security as it is inside the Kubernetes cluster, which confines data usage internally.

Regarding areas for improvement in Tekton, I have not encountered significant issues. It works well for our use case. However, incorporating AI could be a potential enhancement in the future.

I have been using Tekton for one year and two months, primarily for a project called Anthem.

Throughout my one year of usage, I have not faced any stability issues with Tekton. It handles multiple services and deployments efficiently.

Tekton automatically scales up when needed, such as when multiple developers push code simultaneously. It does this effectively without causing any issues.

We have not had any need to escalate issues or contact technical support because Tekton has been functioning well for our needs.

Positive

Before Tekton, we used Jenkins and Skaffold. While Skafold lacked a dashboard and had other limitations, Tekton offers a user-friendly interface and various benefits for CI/CD processes, which makes it preferable.

The initial setup of Tekton was straightforward, with comprehensive documentation available. This made the process clear and accessible.

Two people manage Tekton, with my colleague handling the initial setup, and I focus on creating tasks and pipelines.

Using Tekton has resulted in cost savings. It required fewer resources compared to Jenkins, running efficiently within a Kubernetes cluster without high memory or CPU usage.

Setting up Tekton has been cost-effective, as it can run multiple pipelines simultaneously with limited resources, unlike Jenkins, which had higher resource consumption.

We previously used Jenkins and Skaffold but switched due to Tekton's advantages in simplicity, UI, and effective resource management.

I am preparing documentation to compare Tekton and Jenkins for a new project. The goal is to highlight Tekton's benefits and potentially advocate for its adoption.

I'd rate the solution ten 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. 

We are using Tekton for continuous integration and continuous delivery to deploy our code to production.

By using Tekton, we have streamlined our deployment process and enabled continuous integration and delivery, which is crucial for maintaining our production systems.

The most valuable aspect of Tekton is its Kubernetes maintenance, allowing us to use it anywhere that supports Kubernetes. It is an open-source tool, which makes it highly adaptable.

Improvements could include introducing a UI-based pipeline development feature, such as drag and drop, which would help individuals with limited technical knowledge start building pipelines. However, I acknowledge that might be too ambitious.

I have been using Tekton for over six months.

We have experienced some performance issues with our clusters, leading the deployment team to create new clusters for enhanced performance. Teams are in the process of migrating to these new clusters.

Scalability-wise, Tekton should be adequate since it supports Kubernetes natively. Although I have limited knowledge in this area, it should scale by adding pods and clusters.

I have only received communications regarding migration from customer service. There haven't been any significant issues requiring their contact.

Positive

Previously, I was not involved in using any CI/CD platform, as there was a separate deployment team handling it. Therefore, Tekton is my first experience with a CI/CD solution.

The initial setup was challenging due to the various core concepts involved and multiple required connections, such as GitHub and cloud. Understanding triggers, events, and pipelines was important, but it posed a learning curve.

The setup process was managed by involving a senior colleague with experience, which aided in deploying successfully.

It is an excellent choice for CI/CD, primarily due to being open source and Kubernetes-native, which avoids vendor lock-in and allows flexibility in backend changes with minimal settings adjustments.

I'd rate the solution eight out of ten.

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.

Neutral

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.