Helm chart best practices : latest tag or not

Question

I'd like to know what are your best practices (or just your practices) regarding the management of your helm charts versions.

I wonder what is the best way to deal with application versioning, continuous integration/delivery and chart packaging.

Today I have many microservices that live their life. Each one has its own lifecycle and it own versioning in its own git repository.

Beside, we choosed to have one git repository for all our charts.

Now, we have too choices :

• Each time a microservice changes, a new docker image is built and a new version of the chart is created too (with just the tag(s) of the docker image(s) that change in the value.yaml file)
• Or, even if a microservice changes, we don't create a new version of the chart. The default value of the docker tag in the chart is set to "default" and when we want to upgrade the chart we have to use --set image.tag=vx.x.x flag.

The benefit of the first approach for the "ops" point of view, is that at any time we know what version of each chart (and each docker image) are running on the cluster. The drawback is that at a certain time we will have many many versions of each charts with just a docker tag version that changed.

On the other side, the benefit of the second approach is that the only thing that makes the chart version to change is a modification of the chart code itself, not an application change. It reduces drastically the "uselessly" high version numbers of each chart. The drawback is that we have to override the docker tags at the installation/upgrade time and we lost the observability of what versions are running on the cluster (usefull in case of Disaster Recovery Plan).

So, what are your practices? Perhaps an hybrid approach?

Thank you for your help

Answer 1

I think this is a choice that comes down to the needs of your project. An interesting comparison is the current versioning strategy of the public charts in the Kubernetes charts repo and the current default versioning strategy of Jenkins-X.

The public charts only get bumped when a change is made to the chart. This could be to bump the version of the default image tag that it points to but each time it is an explicit action requiring a pr and review and a decision on whether it is a major, minor or fix version bump.

In a Jenkins-X cluster the default behaviour is that when you make a change to the code of one of your microservices then it's chart version is automatically bumped whether or not the chart itself changes. The chart in the source repo refers to a snapshot but it is auto deployed under an explicit version and that version gets referenced in the environments it is deployed to via a pipeline. The chart refers to a draft/dev tag of the image in the source and that's also automatically replaced with an explicit version during the flow.

The key difference I think is that Jenkins-X is driven towards a highly automated CI/CD flow with particular environments in the flows. Its approach makes sense for handling frequent deployment of changes. The public charts are aimed at reusability and giving a stable experience across a hugely wide range of environments and situations through public contributions. So the strategy there is more aimed at visibility and ease of understanding for changes that you'd expect to be less frequent by comparison.