Helm is advertised as pretty much "the way to manage the deployment of apps on k8s".
We have microservices whith a 1-to-1 mapping of code repo and deployable, and I would find it much more convenient to have the k8s config map along with the code, so that they evolve together, e.g. when adding a new environment variable for a feature flag.
However, we maintain instead a single helm charts git repo, that would need to be occasionally updated in sync with the code.
What is the best practice:
Hope it is not too generic or opinionated, but happy to edit to make it more concrete.
We've encountered some of these same questions on the Activiti cloud project so can answer based on my experience:
1 When to use helm charts? Is it applicable when having 1-to-1 mapping of code repo and deployable? Or mainly to coordinate deployment of composite apps?
If you find yourself needing different configurations for different environments then helm can be useful. Even more useful if you've got external consumers who also want to use your deployables and deploy with them to their own environments or extend or further configure the deployable.
2 Have you been using successfully helm chart per repo (isntead of a single repo for all charts)?
We have done this for some purposes and it's the default if you work with Jenkins-X, which gives you an opinionated kubernetes cluster set up for a particular way of doing CI/CD. It includes a chartmuseum in that cluster and when you build an app in Jenkins-X using its default pipeline then the chart is published to the internal chartmuseum.
However, we've also used a single repo. That is a natural way to go if you're hosting your charts using a github pages repository as it makes it easier to build the chart packages and publish them if the source is in the same place as where they are hosted. I don't think this is necessary though - if you set up your CI to do so you should be able to add packaged charts to the docs directory and re-index the repo. It would mean that your CI for each project would need to make commits to the helm repo project.
3 If using vanilla k8s config map for configuring the deployment out of a git repo, what issues have you faced? I.e. when do you start needing helm?
As with 1, you really get value if you need to be able to change config at deploy time (e.g. to set a url that is specific to a cluster) or distribute to allow others to create new packages that override the defaults. It might also help to be able to externalise some config as deploy-time parameters so that specific parameters don't have to live in git (e.g. you might want to do this with certain passwords).