Tekton Reviews

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.

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.

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. 

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.

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.

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. 

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.