In our GitOps setup using Kubernetes, Helm, and Argo CD, we have separate Git repositories for our development and production environments for security and compliance. Each repo contains the same Helm chart, a values.yaml file, and ConfigMaps and Secrets. Generally, best practices suggest promoting application versions (like image tags) rather than environment configurations. I'm curious whether it's ever acceptable to promote the values.yaml file directly from development to production or if it should always be kept environment-specific. For instance, would a workflow like creating a Git tag in the development repository and then copying it to the production repo for deployment make sense, or is this considered a bad practice?
5 Answers
It really depends on the specific values you're dealing with. Certain values, like hostnames or specific resources, should remain environment-specific. In cases where values could be the same across environments, it might be beneficial to promote them. If that's the case, you might as well include them directly in the Helm chart and promote the chart version instead of just the values.yaml file. Just a thought!
The bottom line: promotion of values is not a one-size-fits-all situation. It heavily depends on how your application is structured and what specific variables you're handling. For our projects, we often set up shared configurations for replicas or image repositories that are relatively stable across environments while managing specific resource requests for each environment separately. This can help reduce duplication and confusion as teams scale up their deployments.
We handle this by having distinct values files for each environment. For instance, dev has values.yaml and values-dev.yaml, while prod has values.yaml and values-prod.yaml. When promoting from dev to prod, we simply copy the relevant dev values file over to production. This way, environment-specific configurations stay in their own files while still allowing some shared values, like image tags, to be in the common values.yaml.
We actually use two separate GitLab servers for our different environments!
Having separate repositories for each environment can complicate things more than necessary. In your case, some values are tied to the application version and should be promoted along with the app, like config parameters. But others are environment-dependent, like resources, and don’t need to be staged. Even resource requirements can change with new app versions, so it's not strictly decoupled. It’s all about finding a balance and understanding what needs to change with app versions.
What’s the downside of using one branch per environment in a single repo? How are you managing it otherwise?
It's frustrating how helm makes it hard to manage all of this effectively!
Take a look at Kargo—it’s a solid approach for managing multiple environments more effectively! It might help streamline your process.
I'm definitely going to try it out!
Sometimes I think shared values can lead to more confusion than convenience!