Continuous Deployment should include automated production testing and rollbacks

When describing Continuous Deployment, it often gets simplified down to automating production code deployments. It's often described as when a developer pushes a change, the changes are tested in a CI/CD pipeline and then automatically deployed to production without human intervention.

A popular way to implement Continuous Deployment for Kubernetes is using GitOps. Typically with GitOps, once changes are merged to a repository's main branch, they are reconciled and applied on the cluster(s) automatically without any intervention.

Continuous Deployment shouldn’t just stop at simply deploying changes, however. It should also include automating post-deployment testing, as well automatically rolling back if test results are unsuccessful (Spurin 2025).

Using the GitOps example again, testing deployments against metrics and performing automated rollbacks is often accomplished with Progressive Delivery tools such as Flux Flagger or Argo Rollouts. More specifically, GitOps is used to sync specialized deployment manifests for applications, and then custom controllers in the cluster(s) handle the progressive deployment within the cluster ^[1].

References

Spurin, J. (2025, January). Kubernetes Certified (KCNA) + Hands On Labs + Practice Exams. Udemy.

Whereas continuous delivery would require an initiation by a human, continuous deployment is a practice where changes are continuously deployed and released into a production environment.

It's important when considering this approach that there should also be a further emphasis on the ability to test in production, as well as things like automated rollback procedures for production.