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.

Deploying software to your internal systems or sending releases to external customers is a process that ideally follows strong security requirements in an end-to-end manner. In a perfect world, every software release should come with at least the following guarantees In the world of CI/CD we are mostly interested in binary artifacts and how they were created all the way from the initial release up until they reach production.

In September 2023, security researchers from KTrust reported three issues through the official Argo CD security disclosure channels in accordance with Argo CD security policy. In coordination with other Argo maintainers, we have issued security updates for both Argo CD and Codefresh GitOps (enterprise Argo). Below you can read more about these CVEs, their impact, and mitigation.