I'm currently working with Kubernetes, Helm, and Argo CD using a GitOps strategy, where we have separate Git repositories for each environment (development and production) on different GitLab servers due to security and compliance protocols. Each repository contains the same Helm chart, a values.yaml file, and relevant ConfigMaps and Secrets. I've come across the common suggestion in the GitOps community that we should promote application versions (like image or chart tags) but refrain from promoting environment-specific configurations like values.yaml. I'm wondering if it's ever considered a good practice to promote values.yaml from dev to prod, or if those configurations should always remain unique to their environments and managed separately. For example, would a workflow where I create a Git tag in the dev repository, copy it to the production repository, create a branch from there, and deploy the new version of values.yaml to production make sense? Or is this considered an anti-pattern? I'd love to know if anyone has experience with this and your thoughts on whether promoting values.yaml is ever useful or practical.
5 Answers
In our workflow, we have a common values.yaml for shared settings, and then separate environment-specific values files. This allows us to promote essential shared configurations across environments while keeping sensitive or unique settings isolated. It's all about finding the right balance that suits your deployment pipeline!
I lean towards using Kustomize for managing different environments, as it can help with layering custom configurations without the complexity of merged values files. Using Kustomize with Argo CD can simplify the management of various configs and reduce deployment headaches caused by environment differences.
We’ve adopted a setup with separate values files for each environment, like values-dev.yaml for development and values-prod.yaml for production. When promoting from dev to prod, we just copy the dev values file over, keeping critical environment-specific settings in the prod file. This gives us a clear distinction while still allowing us some flexibility in managing the common configurations.
I think it really depends on the specific values you're dealing with. Some, like hostnames and resources, should definitely remain environment-specific. If some values can actually align between dev and prod, consider integrating them into the chart directly and just promoting the chart itself instead. That way, you keep your environments clean and avoid potential conflicts later on.
It's generally accepted that some values in your values.yaml might change with app versions, like certain config parameters. Those could be promoted alongside the app. However, many values, especially resource definitions like limits and requests, should be environment-specific. So, promoting values.yaml directly might not be the best idea since production and dev environments often require different configurations. Coupling them can lead to issues when the application changes. I'd suggest keeping them separate unless you're very sure a specific change applies to both environments.

Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically