The continuous integration and delivery/deployment (CI/CD) paradigm helps developers and engineers make incremental changes frequently and with quality in mind. As organizations shift-left their quality, security, and policy efforts to the pre-deployment phases of development, they can minimize the burden this places on developers by automating more and extending their CI/CD pipelines.
When you add testing in CI/CD, you can enable and automate all kinds of powerful and valuable tests:
- API testing (Postman, SoapUI)
- Load testing (k6)
- Front-end testing (Cypress)
- End-to-end testing (Playwright)
- … and more
Whenever you or other developers/engineers commit code, create a pull/merge request, or merge changes into your `main` branch, your CI/CD pipeline runs these tests sequentially and informs you about their results.
All that sounds great, but when developers/engineers are working with cloud native Kubernetes environments, the path to successfully testing in CI/CD isn’t quite clear.
Why is testing in CI/CD a challenge for Kubernetes?
Simply put, the most popular CI/CD tools, like GitHub Actions, weren’t designed with the unique properties of Kubernetes in mind. Your CI/CD pipeline and cluster operate separately, but entirely dependent on one another, which means
- Popular testing tools/platforms don’t natively support Kubernetes. Even though they predate the entire cloud native ecosystem, tools like Cypress and Postman typically run by pinging an API or browsing your front-end, there’s no way to integrate the execution with the build/deployment of your cluster without tightly integrating them with your CI/CD pipeline, which leads to complex-to-maintain monoliths.
- Testing Kubernetes in CI/CD creates tightly-coupled, and hard-to-maintain pipelines. Because your CI/CD pipeline can’t run tests directly, but rather needs to leverage “sidecar” Docker containers, you can’t run tests without your CI/CD, and you can’t run just a single test—it’s the whole pipeline or nothing at all. Plus the security, networking, and maintenance challenges of daisy-chained monoliths.
- You have to build the “glue” yourself. Whether you’re using Argo, Jenkins, GitHub Actions, or another CI/CD tool, you have to spend time integrating your testing tools onto a single platform, which effectively blocks you from quickly trying out new and potentially better tools and ultimately locks you into the CI/CD tool you’re currently using.
Instead of letting developers leverage the small, independent, and composable benefits of microservice architectures, CI/CD becomes less of a pipeline and more of a bottleneck for robust, complete testing.
The path Kubernetes-friendly testing in CI/CD
Instead of building another complex monolithic CI/CD pipeline, you can opt for a test orchestration and execution platform that utilizes native Kubernetes objects (CRDs). The big difference is that instead of your tests being executed by your CI/CD pipeline, they’re executed from within your cluster itself.
You can utilize the power of your cluster to scale your testing efforts, and your CI/CD pipeline gets a whole lot simpler—instead of custom glue and sidecar containers, you can run tests by simple API calls.
Native testing also lets you integrate your test orchestration and execution into your ongoing GitOps efforts for all the additional benefits of having a single source of Kubernetes configuration truth and a full audit log.
One such solution for native Kubernetes testing in CI/CD is Testkube. We’re open source, completely free to use when self-hosted, and work with your favorite testing tools for robust coverage and high-quality software.
Start testing in CI/CD on a framework that works with Kubernetes, not against, in just a few minutes.
Give it a go!
Why not give it a go yourself? Sign up to Testkube and try one of our examples or head over to our documentation - if you get stuck or have questions, we’re here to help! Find an answer to your questions in the Testkube Knowledge Base or reach out to us on Discord. We’re eager to hear how you use our integrations!