Re: Helm versioning and CI/CD


Loritsch, Berin <bloritsch@...>
 

It does help.  The main thing I'm looking for is to wrap my head around the thinking into how versioning was designed to work with helm.  It's a big difference between saying "yeah that's a thing that can be done" and understanding what the ramifications of my choices are.

That being said, there are some things I want to change in the sample charts I created.  I'll try to derive some inspiration from the CI definition you provided.

On Mon, May 4, 2020 at 4:02 PM Matt Farina <matt@...> wrote:
Berin,

I am not entirely sure of your workflow so these are just ideas and thoughts in the area.

First, appVersion is optional. You do not need to use it if you don't want to.

Second, if you are using the `helm package` command there are flags to pass in the version and appVersion.

Third, it is possible to alter things in CI. I was reminded of an example Antoine Legrand put together a few years ago. You can find it at https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml.

The neat thing about the 3rd example is you can have a tag or even get a hash for a container image and then use that in the new chart version.

Does any of this help?

- Matt Farina

On Mon, May 4, 2020, at 1:17 PM, Loritsch, Berin wrote:
I'm in the process of writing up my recommendations for how to integrate Helm into our build and deployment infrastructure.  I have a few questions that I need to understand better.  The most important one has to do with how versions are intended to work with Helm.

There are two versions to worry about in any given helm file:
  • Chart Version {{.Chart.version}}
  • Application Version {{.Chart.appVersion}}
The way I understand it, Helm charts deal with _how_ something is deployed, and the container(s) itself deals with _what_ is deployed.

In a shop where we do continuous integration/continuous deployment we need to come up with the policies for how we manage versions.  For example, we have the policy that containers are built and tagged based on the code branch or tag we are building from.

Since the chart has two version numbers embedded inside, I was wondering if there are command-line arguments to override any value.  The chart itself is not going to change unless we find a defect in it.  It would work with our CI/CD infrastructure if we overrode the .Chart.appVersion with the branch name when we do the full build.

If that is the case, we can build our chart as if it is production, and simply override versions when deploying specific versions of an application.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708





--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708

Join cncf-helm@lists.cncf.io to automatically receive all group messages.