This article is adapted from a 2020 expert roundtable originally published by JAXenter, featuring practitioners from the Continuous Delivery Foundation, JFrog, GitLab, OpenDev, and other organisations. Their perspectives remain highly relevant to teams navigating cloud-native CI/CD today.
How Kubernetes Changed Software Delivery
The widespread adoption of containers and Kubernetes has fundamentally altered how software is packaged, tested, and shipped. But the change has not been a simplification — at least not uniformly.
Greater Complexity Demands Rigorous CI/CD
Tracy Miranda (Continuous Delivery Foundation) emphasises that the move to distributed, cloud-native systems raises the stakes for teams that have not properly invested in CI/CD pipelines:
“In a distributed system, with multiple environments, if you haven’t set up CI/CD you can end up in big trouble if something goes wrong. Things you might have gotten away with before are quite difficult to get away with in a cloud native world. Combine that with the proliferation of new tools in the industry — tools that don’t necessarily interoperate well — and it is very difficult for users to know what is best.”
This complexity was a key driver behind the formation of the Continuous Delivery Foundation (CDF), which aims to foster collaboration, set standards, and help teams navigate an increasingly fragmented tooling landscape.
Containers as the Standard Packaging Format
Clark Boylan (OpenDev) makes a practical observation about how container adoption has changed user expectations and CI/CD workflows:
“Containers have become the expected packaging format for software. Potential users expect prebuilt container images that they can start and immediately begin evaluating your software. From a CI/CD perspective they present a convenient format to ensure the software you tested and is known to work is the same software you deploy into production.”
He also notes that Kubernetes encourages developers to think in terms of composable microservices — but that this shift introduces new testing and integration challenges on the CI side, particularly when multiple services must be tested together.
Microservices Acceleration and the CD Imperative
Priyanka Sharma (GitLab) frames the relationship between microservices and continuous delivery as inseparable:
“Developers can build faster with microservices. However, that is not useful if the code cannot be tested and rolled out quickly as well. So, the age of Kubernetes has ushered in the age of continuous delivery and deployment.”
Identical Deployments Eliminate Last-Minute Production Chaos
Joonas Lehtimäki and Nir Koren both highlight the consistency benefit of containers. Lehtimäki explains:
“If you think about how people deployed software before that, the actual process was slow, and it was hard to keep all systems identical. Containers tackled that issue by packaging all the necessary ingredients to a single package. That made every single deployment identical. Kubernetes then just made it easy to deploy on a bigger scale, solved networking issues, and so on.”
Koren adds a concise operational insight: because the container image is nearly identical between dev and production environments, teams experience far less unplanned chaos after production deployments.
Lehtimäki also cautions that Kubernetes is not the right solution for every workload. For a simple static web application, for example, a managed platform-as-a-service offering may be a better fit than running a full Kubernetes cluster.
Reproducibility Enables Small Teams to Operate at Scale
Christian Uhl highlights how the reproducibility of containers, combined with Kubernetes orchestration, democratises advanced deployment strategies:
“With these technologies, we can perform the same clever deployment strategies with one team of software engineers that needed whole departments of people before. This allows small players to play in the big league — so to speak.”
He also acknowledges a well-known tradeoff: the same abstraction layers that simplify operations can produce exceptionally hard-to-debug problems when things go wrong.
CI/CD Tool Recommendations from Practitioners
When asked which tools they recommend — including lesser-known options — the experts highlighted a mix of mature open-source projects and newer cloud-native entrants.
Jenkins X and Tekton: Cloud-Native CI/CD
Tracy Miranda recommends Jenkins X for teams building modern applications on Kubernetes. Despite sharing a name with the original Jenkins, Jenkins X is architecturally distinct: it is purpose-built for Kubernetes-native workflows.
- Pipeline automation out of the box
- Built-in GitOps for declarative, auditable deployments
- Preview environments so teams can review changes before merging
- Built on Tekton, an open-source cloud-native pipeline engine under the CDF umbrella
Tekton itself is noteworthy as a foundational building block: several other CI/CD tools are built on top of it, and it is worth tracking for teams evaluating the cloud-native CI/CD ecosystem.
GitLab CI/CD
Priyanka Sharma recommends GitLab CI/CD — unsurprisingly, given her role at GitLab, but it remains a widely adopted, fully integrated option for teams that want source control and pipelines under one roof. She also anticipates increasing standardisation coming from the Continuous Delivery Foundation.
Spinnaker for Continuous Delivery
Baruch Sadogursky (JFrog) recommends Spinnaker specifically for continuous delivery and deployment use cases, noting that despite being a mature project it continues to improve. He also flags CircleCI as a tool that has embraced cloud-native conventions — building in the cloud, using containers, and relying on configuration-as-code.
Zuul: Project Gating at Scale
Clark Boylan highlights Zuul as a purpose-built CI/CD tool with a specific strength: project gating — the ability to test complex combinations of changes across multiple repositories before any single change merges.
“As microservices become more prevalent you need to be able to test the combination of many different pieces of software all working in concert. Zuul is able to test these change combinations and does so before a single change merges.”
Zuul is self-hosting (it tests itself), and is used in production by organisations ranging from the OpenStack project to BMW and Volvo — demonstrating that its applicability extends well beyond pure open-source software development.
Key Takeaways for DevOps Engineers
- CI/CD is non-negotiable in cloud-native environments. The distributed nature of Kubernetes-based systems amplifies the risk of skipping or under-investing in automated pipelines.
- Container image parity between dev and prod is one of the most impactful operational improvements teams report after adopting containers.
- Kubernetes is powerful but not universal. Evaluate whether your workload actually benefits from Kubernetes overhead before committing to it.
- The CDF ecosystem is maturing. Projects like Tekton, Jenkins X, and Spinnaker are converging around shared standards — worth tracking for long-term tool selection decisions.
- Multi-repo integration testing is an underappreciated CI challenge in microservices architectures. Tools like Zuul are designed specifically to address it.
- Smaller teams can now run advanced deployment strategies (blue/green, canary, rolling updates) that previously required dedicated operations departments.
This roundtable was originally conducted by JAXenter in early 2020. Tool versions, project statuses, and organisational affiliations may have changed since publication.