Tekton Reviews

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 are utilizing Tekton as a pipeline tool for their CI/CD process, which involves connecting GitLab to Nexus, then Nexus to Argo CD, and ultimately to Kubernetes.

We are a Kubernetes-centric company, so it's advantageous for us to use a cloud-native, Kubernetes-driven solution. Tekton is serverless and runs on OpenShift, and we leverage Tekton to take full advantage of the Kubernetes features such as running and scaling the solution in PaaS.

There is a need for substantial improvement in connecting with other tools and open-source software. Configuring Tekton requires a deep understanding of Kubernetes, which can be difficult for developers. Furthermore, there is no existing template that gives defaults for developers to build a pipeline, making it challenging for them to use. In conclusion, Tekton is not particularly user-friendly for developers and has room for improvement.

I would like Tekton to change its dashboard to be similar to the one GitLab offers.

I have been using the solution for one year.

We are not relying heavily on Tekton or OpenShift for stability since our applications used in the DevOps culture are not critical ones, thus reducing the risk.

Tekton is a scalable product that we have not yet taken full advantage of. Although our needs are relatively simple, focusing on DevOps delivery, we have not reached the desired level of use.

Setting up Tekton initially was not a simple process. We did not choose to use Tekton, but rather it was selected due to its availability. IBM promotes Tekton and its integration with OpenShift, so when we set up OpenShift a year and a half ago, we also set up Tekton. We have already implemented GitLab Runner for multiple projects, replacing Tekton. GitLab Runner has been found to be advantageous for developers, due to its ease of use. As a result, we are now running two distinct pipelines for different projects, with the majority of developers preferring GitLab Runner over Tekton.

I give the initial setup a five out of ten.

The implementation of Tekton took some time due to operational challenges, rather than a lack of technical knowledge. These challenges included a lack of understanding of Tekton and the availability of the infrastructure personnel. The overall implementation took us around one month.

We collaborated with IBM and Red Hat vendors to set up the OpenShift PaaS solution. To ensure a successful outcome, we conducted a proof-of-concept (POC) in parallel with the vendors.

I give the solution a five out of ten.

We have around 50 people using the solution in our organization.

From a usage perspective, people are trying to move up from Tekton to GitLab in our organization.

Using Tekton depends on the strength of our Red Hat resources. I recommend GitLab over Tekton.

We use Tekton for CI/CD automation, continuous integration, continuous deployment, and general-purpose automation.

The platform's most valuable features are the cloud-native approach and atomicity. Unlike other monolithic solutions, it is early in adopting a cloud-native platform for CI/CD, which enhances scalability. Additionally, its ability to operate at a granular level allows us to create small automation jobs and combine them into larger tasks, making it very useful.

One project involved automating our deployment processes across multiple environments. By leveraging the solution, we reduced deployment times significantly and increased reliability, allowing for more frequent releases and improved overall productivity.

The product's scalability can be challenging when multiple users access it simultaneously. We have seen some resource crunches, typical for any product supporting a large user base. 

One of the main challenges has been managing complex pipeline dependencies. As the scale of our projects, ensuring that all dependencies are correctly defined and executed in the right order can become cumbersome.

Integration is an area where it lags compared to other CI/CD tools like Jenkins, which has a rich plugin ecosystem. It lacks sufficient vendor support for plugins, requiring users to write their integration scripts, which is less convenient.

Enhancements in documentation and user onboarding would be beneficial. Clearer guides and tutorials could help reduce new users' learning curves and facilitate smoother integration with existing workflows.

The support team is knowledgeable and responsive when resolving issues, though improvements in onboarding and documentation could further enhance the overall experience.

Neutral

The initial setup was somewhat complex, requiring a thorough understanding of Tekton's structure. Once configured, it provided a flexible and scalable solution for our CI/CD needs.

We implemented the product with the help of our in-house team. 

We evaluated other CI/CD tools before choosing Tekton. Tekton's flexibility and cloud-native approach were key factors in switching.

The platform's custom tasks feature allows organizations to create standardized team tasks. It enables enterprises to build a flexible framework atop Tekton, making it easier to define workflows with standard inputs and outputs.

It does not differentiate between continuous integration and deployment, offering a unified framework. It provides tooling to run code that builds or deploys applications, allowing for flexible task configurations and parallel processing.

We manage version control through Git repositories, where we store our Tekton pipeline definitions. It allows us to track changes and revert to previous versions, maintaining a robust versioning system for our CI/CD processes.

It has the potential to be a long-term solution due to its scalability and flexibility. However, continuous improvements in user experience and community support will be key factors in its sustained adoption within our organization.

Security is managed through role-based access controls (RBAC) and secret management features. We ensure that sensitive information, such as API keys, is stored securely and that only authorized users can access critical pipeline functions.

Overall, I rate it a six out of ten.

I use it for the CI/CD pipeline. The client wanted to create a pipeline for this workflow to be deployed in his kubernetes cluster whenever he made changes. We had three different pipelines for three stages: one for dev, one for production, and the other for QA. The client was unfamiliar with this process, so he wanted us to create three different environments to eliminate manual processes.

With the help of Tekton Hub, we accessed example tasks that were very useful for everyone involved. From that hub, we took a sample task and created our own. It was straightforward to set up. We built the software image, and once that was done, we implemented the deployment process in the same pipeline, where the Helm Chart gets updated with the image name using the check command.

We also integrated the branch nodes through the request process, making it easy to trigger deployments cleanly. Compared to other tools like Argo CD and Argo Workflows, we found them very helpful, as they require different UIs and workflows.

The most valuable features are trigger functionality and the dashboard because they easily highlight our errors. Tekton allows us to see both CI/CD in one place. Unlike other products, Tekton makes managing the entire CI/CD process much easier than separating it into different parts. 

Tekton could use better documentation. We struggled due to the lack of clear documentation for triggers. Everything else was documented very well, but that section needs improvement.

I have been using Tekton for one year.

Tekton is very stable. They release a beta version approximately every two months, but they maintain the stable version until they are confident that the beta version is ready for use.

Scaling up and down is straightforward. The cleanup process in the pipeline section is also very easy. We can quickly delete any tasks.

We never had a chance to contact the support team.

Tekton is open source, so we never encountered any pricing issues. We were able to use it free of cost from end to end.

I was part of the DevOps team, and once our developers completed their code, it was easy for us to trigger workflows. When they wanted to deploy to different environments, like from development to QA and then to production, Tekton made it very user-friendly. Developers often lack knowledge of operations, so they don’t always know how to trigger processes. With Tekton, we managed to achieve this seamlessly without requiring developer intervention.

Tekton is easy to use for someone familiar with the CI/CD process and who has experience with manual authorization and deployment in Kubernetes. There may be a learning curve for beginners, but anyone with basic knowledge of Docker and Kubernetes will find it easy.

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