Testing Deployments in Kubernetes with FluxCD and Helm
Throughout my career, I’ve helped set up numerous production-grade Kubernetes clusters. While there are many problem domains in that area, today I’ll be focusing on testing.
The Challenge of Testing in Kubernetes
Testing in Kubernetes has never been easy. Questions such as “What kind of testing would you like to do?” or “When should the tests run?” are difficult to answer — not just in Kubernetes, but in DevOps as a whole.
When using GitOps as a deployment model on Kubernetes, one of its core benefits is fast deployment. GitOps promises that committed code enters a reconciliation loop, eventually resulting in scheduled workloads on, for example, a Kubernetes cluster.
Why Testing Matters in GitOps Workflows
Since code is typically committed many times a day, any testing framework that runs alongside a deployment should be easy to use, flexible, and ideally integrated into your deployment system.
This is where FluxCD comes in.
Introducing FluxCD
FluxCD is a delivery solution for Kubernetes that implements a GitOps operator.
I won’t go into detail about GitOps operators or FluxCD in general — you can explore those topics in the official documentation.
Instead, I want to highlight a powerful feature from their HelmRelease CRD.
Leveraging Helm Tests with FluxCD
The idea is simple: when deploying to Kubernetes, we want to run a series of tests to ensure that our deployment is successful.
Helm provides an excellent testing framework, and FluxCD integrates directly with it. In the test configuration section of the documentation, FluxCD specifically enables us to run Helm Tests as part of both install and upgrade processes for any HelmRelease.
This means we can write tests in Helm and have them automatically executed during an install or upgrade. The deployment will only be reported as successful to the FluxCD controller once all tests pass.
Automatic Rollbacks and Safer Deployments
This is a powerful capability — one that I haven’t seen utilized often.
Essentially, we can instruct our deployment controller to roll back a deployment automatically if any tests fail.
We can also run tests during installation to verify that specific resources are created or configured correctly, ensuring that everything behaves as expected before marking the deployment as complete.
Confidence and Control in Your Deployments
Running Helm tests during every install and upgrade in FluxCD gives us a high level of confidence that our deployment is successful.
It also allows us to define specific tests that serve as rollback triggers when they fail. With this approach, you gain the confidence and control that many large organizations require for production deployments.
In the environments where I’ve implemented this setup, install and upgrade errors have been reduced to almost zero. And when an error does occur, it’s straightforward to pinpoint the issue — since a failing test will clearly indicate what went wrong.
If no test fails but the deployment had an error, remember to add a test for that scenario in the future — continuous improvement in test coverage is key to long-term reliability.
Top comments (0)