In our big guide for Kubernetes deployments, we explained the benefits of using dynamic environments for testing. The general idea is that each developer gets a preview environment instead of having a fixed number of testing/QA environments. The environment gets created on the fly when you open a pull request. Typically, it gets destroyed when you merge the pull request (or after a specific amount of time).

Have you ever found yourself wrestling with the complexities of managing ArgoCD applications across multiple environments? Are you constantly juggling naming conventions and struggling to correlate applications representing the same microservice or product? If you’ve been deep in the trenches of GitOps, you’ve likely encountered these challenges firsthand.

In the previous article of the series we explained how to model GitOps environments and promote an application between them. That article was laser-focused on a single application and its Kubernetes resources. In this article we will zoom out to look at several related subjects: It is worth mentioning that as always, our advice is a general recommendation that follows best practices.