To help automate CI/CD with GitOps we assume helm charts are created as part of the automated project setup and CI/CD. e.g. just import your source code and a docker image + helm chart will be generated for you - the developers don’t need to know or care if they don’t want to use helm:
If a developer wants to specifically create a specific resource (e.g.
Secret, ConfigMap etc) they can just hack the YAML directly in
charts/myapp/templates/*.yaml . Increasingly most IDEs now have UI wizards for creating + editing kubernetes resources.
By default things like resource limits are put in
values.yaml so its easy to customise those as needed in different environments (requests/limits, liveness probe timeouts and the like).
If you have a developer who is fundamentally opposed to helm’s configuration management solution for environment specific configuration you can just opt out of that and just use helm as a way to version and download immutable tarballs of YAML and just stick to vanilla YAML files in, say,
Then if you wish to use another configuration management tool you can add it in - e.g. kustomise support.