Tekton Reviews

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.

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.

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.

When we started with Tekton around 2021 or early 2022, the community support was somewhat limited, which posed challenges when dealing with issues or debugging. We had to rely on Red Hat OpenShift support to overcome these challenges. However, I believe that these issues will naturally improve over time as the developer community grows stronger. From a technical perspective, I haven't had the opportunity to deeply evaluate the product end-to-end, especially in the past year or so, when I've been less involved with it.

During my time at Deloitte, I worked on a project using Tekton. I have one year of working experience with the tool.

Tekton is generally stable, although we observed occasional minor issues or bugs. I don't believe these were major issues caused by Tekton itself. It could have been due to configurations or other factors we missed initially. We were able to identify and fix these issues later on. But in general, Tekton is stable, and there's always room for improvement as it matures.

Since the Red Hat community developed Tekton, we had strong support from our Red Hat subscription. This meant that if we encountered any issues, we could directly contact the Red Hat technical team for assistance, and they were able to support us. By following the documentation and clicking through the necessary
steps in OpenShift, all the components were automatically set up behind the scenes, making Tekton ready to use without much hassle.

The initial installation and setup of Tekton were relatively straightforward and not too time-consuming. The documentation provided clear instructions on setting up the base Tekton server configuration. Additionally, integrating Tekton with Red Hat OpenShift was made more straightforward due to the platform's user-friendly plugins.

It is worth the investment because, from my perspective and expertise, it proves to be beneficial when used efficiently. For instance, if we compare it to running a Jenkins server, which has limited resources and can handle a specific number of applications, Tekton can provide better scalability and efficiency at a larger scale.

If you're dealing with many applications and need a reliable, scalable, and efficient system, I'd recommend going with Tekton, as it's more mature and has a growing developer community. However, if you prefer sticking to traditional technologies like Jenkins, especially if your team is already familiar with them and needs a quick ramp-up, that's also a viable option.

I would rate the solution an eight out of ten.

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.

It is an open-source tool initially developed by Google for internal use, later open-sourced, and widely adopted for building and deploying applications in Kubernetes environments. When deployed in a Kubernetes cluster, Tekton seamlessly integrates with the environment, streamlining the application pipeline delivery process. It automatically triggers when code is merged into the main branch, operating natively within Kubernetes without requiring additional external components. The automated pipeline, initiated by Tekton, builds the application, deploys it to specified container registries, and then to the Kubernetes cluster. Tekton's versatility shines in multi-environment setups like staging, testing, and production, efficiently managing the continuous integration (CI) part by triggering processes linked to code merges. Users often integrate Argo CD to complement Tekton in the continuous deployment (CD) phase. Argo CD pulls and deploys the latest application image within the Kubernetes cluster, creating a comprehensive and automated CI/CD workflow.

Its user-friendly features include a clean and sleek dashboard. This dashboard provides detailed logs and stages of the pipeline, offering transparency into each step of the process. In case of any failures at a specific stage, the dashboard provides comprehensive information about the issue, enabling quick identification and resolution. Another valuable aspect is its lightweight nature. There's no need for additional deployments or reliance on external vendors for CI/CD, resulting in significant cost savings. Its seamless integration with Kubernetes, being built on top of it and utilizing Custom Resource Definitions, ensures a smooth experience within Kubernetes environments exclusively. Its capability to build entire applications within containers contributes to a seamless and efficient workflow. It stands out for its customizability and scalability, allowing users to undertake diverse tasks.

It tends to occupy a significant amount of disk space on the node, which could potentially pose challenges. This aspect could be enhanced for better efficiency. Additionally, the build time, particularly for larger applications, seems a bit extended, ranging from five to ten minutes in some cases. There's room for improvement to streamline and minimize the build time.

I have been using it for the last six months.

The product appears to be stable, I haven't encountered any noticeable bugs or errors. It has proven reliable in automatically executing tasks once triggered, making it a dependable tool.

The developers' team, consisting of over thirty or forty individuals, actively uses it.

The initial setup was quite straightforward since it comprises various components that are defined separately and then combined to create a pipeline.

Deploying it was easy and seamless, but creating a pipeline involved a bit more effort, requiring attention to various details and taking some time. Despite the complexity of creating pipelines, the overall deployment and readiness of the tool for use were smooth and uncomplicated. Understanding the architecture of this technology is crucial. For newcomers, there might be a learning curve initially, making it a bit more challenging. I am the one responsible for configuring, deploying, and creating pipelines for the development team. I have established a read-only dashboard that provides a clear and concise overview of the pipeline statuses when triggered.

It is entirely open source and free of charge.

While other options like Jenkins were available, Tekton's native compatibility and endorsement by a skilled team of Google developers influenced my decision. It is a stable tool from Google, providing authentication validation for applications. Additionally, I appreciated the seamless integration with Kubernetes, making it a native and well-developed tool for CI/CD processes.

I highly recommend that you operate in a Kubernetes-based environment closely integrated with Kubernetes. However, I suggest deploying it in a separate cluster, not where your primary workloads run, to avoid potential disruptions to production cluster resources. I also recommend it for users who are already familiar with the tool. While it offers significant capabilities, harnessing its full potential requires a certain level of understanding. Overall, I would rate it seven out of ten.

Tekton is the orchestration engine within OpenShift, which is our on-premise platform. Since we are not on the cloud yet, OpenShift plays a strategic role, and Tekton is a significant part of it. It serves as an orchestrator.

In my experience of the last two years using Tekton and OpenShift pipelines, I haven't encountered many issues. As an orchestrator, Tekton works best. It's just one component of the larger OpenShift platform. Tekton consists of multiple components like events, trigger bindings, and more. However, when it comes to the overall OpenShift platform, being a platform as a service, most aspects are taken care of. 

Tekton plays a primary role as an orchestrator. When we receive a webhook from any Git repository, such as Azure Git or GitLab, Tekton triggers the pipeline and performs tasks like code retrieval, running SonarQube or Fortify tasks, and creating and deploying images to multiple environments.

So we can have multiple promoted environments, starting from dev to SIT, then to UAT, and finally to production. We follow a continuous flow branching approach, allowing us to promote changes from smaller environments to larger ones like dev to SIT, SIT to UAT, and UAT to production, which is our master branch. This helps us maintain a smooth workflow and ensures reliable deployment.

Tekton is an orchestrator. It provides seamless integration for our pipelines. It offers robust support for executing tasks within the pipeline, allowing us to set up and run pipelines quickly.

Additionally, Tekton's underlying architecture with OpenShift enables us to create, implement, and run end-to-end pipelines. We can integrate various automation tools like Fortify or SonarQube for testing, code scanning, regression testing, and more. All these tasks can be executed within the pipeline using Tekton.

There might be occasional issues with storage or cluster-level logging, which can affect production. But as a component, Tekton performs flawlessly.

As an orchestrator, Tekton effectively executes most tasks. However, there are instances where we feel that YAML files, which Tekton reads, could benefit from increased flexibility. You see, in OpenShift, everything revolves around YAML. We have different components specified in YAML files, and when we put them together in an OpenShift pipeline, it generally works fine. However, occasionally we encounter difficulties when editing these YAML files.

I have been working with Tekton since we implemented it in 2020, so it's been almost two years.

We haven't encountered any stability issues with it. It has been reliable and available.

Tekton is scalable.

Red Hat's support has been quite excellent. We have a close partnership with Red Hat, as our DevOps strategy heavily relies on OpenShift as a core component. 

Since our entire architecture is on-premise, we have made significant investments in OpenShift. Setting up the OpenShift cluster and configuring different components, including Tekton, has been smooth and hassle-free for us, thanks to Red Hat's support.

It's not solely about Tekton itself. We chose OpenShift as a platform as a service because we opted for on-premise implementation instead of the cloud. The implementation of OpenShift includes the incorporation of Tekton.

The initial setup is actually easy. Tekton is just one of the underlying components in OpenShift pipelines. It's a technology and engine with a straightforward architecture, so the setup process is quite simple.

We have a command-line setup where we use the OpenShift client to connect to Tekton. It's like talking to the cluster, and Tekton executes the tasks on that specific cluster. It's an efficient and streamlined process.

The entire OpenShift platform is supported by just two DevOps engineers.

But we might need to expand the team in the future. Two resources are not sufficient considering the workload and stress we handle.

The pricing is based on OpenShift's vCPU licenses. We pay according to the number of virtual CPUs, which can be costly. 

However, it's important to note that Tekton is just one of the underlying components in OpenShift. Therefore, the pricing and licensing considerations are more related to OpenShift as a whole rather than Tekton alone.

We have evaluated multiple vendors, including Red Hat, whose DevOps architecture includes Tekton as an underlying component. However, other vendors also offer similar orchestration components in their architectures. 

So, there are various tools available from different vendors that serve the same purpose as Tekton.

There are several vendors in the market who provide their own versions of orchestration components for DevOps architectures, apart from Red Hat. They implement their own approaches and name their components accordingly, but the purpose is similar to Tekton.

I would recommend Tekton as an orchestrator because it works well within the OpenShift environment. While there may be similar orchestrator components offered by other vendors in different DevOps architectures, Tekton's integration with other OpenShift components makes it a strong choice.

I would rate Tekton a seven. The only drawback I've experienced is the difficulty of modifying YAML files on the fly and making changes, as it doesn't work well in that aspect. However, apart from that, Tekton performs well in other areas.

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.

It would be better if Tekton could show the YAML file while it is running, similar to GitHub pipelines, to provide more visibility on what's happening. We need information on the duration and specifics of the running pipeline for easier analysis.

It's been one year since we started using Tekton.

Tekton is a stable product. It comes integrated with OpenShift. We can definitely use it, and it supports authorization and authentication, enhancing security.

We can easily scale Tekton as it is integrated with OpenShift clusters.

Previously, I was using a setup PSD pipeline.

The initial setup is not straightforward. We run it on-premises, meaning there must be an open-source cluster with a Tekton pipeline. The pipeline pods should also run in the same cluster.

The implementation is usually handled by the DevOps team.

Pricing varies based on whether the user is an enterprise or individual. Exact pricing details are managed by the company.

I recommend Tekton, but users should have some underlying knowledge about how CI/CD pipelines work.

I'd rate the solution eight out of ten.

I am using Tekton for continuous integration in our project.

The feature that I like most about Tekton is that it is built for Kubernetes, so we can utilize our resources effectively.

Tekton should have more accessibility for some rare use cases so that we can have more references when applying some techniques to our pipeline.

I have been using Tekton since February.

If we set it up correctly and know exactly what we have done, it is very stable because it runs on top of Kubernetes.

I can't give an opinion right now because I haven't applied the scale to our deployment. It's only in our staging environment.

I haven't contacted support yet since most of my errors are addressed in their GitHub repository.

Positive

I had some experience using Tekton when my company migrated the CI panel from another platform.

The initial setup is rather easy because the tutorial is easy to follow.

Tekton is free to use. It's open source.

I would recommend Tekton to my coworkers if they use Kubernetes most at work. However, if my colleagues don't use Kubernetes, I wouldn't recommend Tekton to them because it is very difficult to understand Tekton if you aren't familiar with Kubernetes.

I'd rate the solution eight out of ten.