Helmfile: Support CD to development

[sstarcher]

Say we have a chart that we have deployed to a production cluster.

charts:
  - name: stuff
    namespace: stuff
    chart: ../charts/stuff
    version: 1.0.0
    values:
    - ../values/stuff.yaml

We have this version and it's deployed and everything is great. We have an automated process that when someone commits to master we generate semver values automatically for the next release.

The second commit after the tag would be 1.0.1-1 and the next commit would be 1.0.1-2. We would like to use helmfile to automatically allow support for something along the lines of helmfile sync --devel.

When that is specified we would install any matching pre-release version.

Would this be something that we could consider for helmfile or would anyone have a better workflow idea to support CD using helmfile?

[sstarcher]

Or possibly an option to ignore the version value to cause it to use latest? That partnered with --args='--devel' would likely accomplish what I'm aiming for.

[Stono]

Hey,
Don't know if it helps but we have a script which dynamically checks our helmfile back into git.

You can see in this screenshot each of these pipelines generates a helm chart, and leads into delivery-platform:

The delivery-platform then dynamically updates helmfile.yaml and checks it back into git and tags it:

That tag is then applied through the environments, and ensures that the deployment is completely deterministic.

[sstarcher]

ya, I was hoping to have the helmfile only updated when we were ready for a production update and to allow the versions to float.

[mumoshu]

@sstarcher How would you like helmfile sync --devel to behave when there are multiple releases in your helmfile.yaml?

I was wondering that in some cases you would want to use the devel version only for a specific chart. Say you have mysql and your webapp, you'll probably want to apply --devel only to the webapp?

[sstarcher]

My specific use-case would likely be restricted to targeted --devel updates like.

helmfile -l name=webapp sync --devel

Although if I had a webapp I would not have a separate release for mysql I would pin the version of mysql as part of the webapps chart.

[mumoshu]

helmfile -l name=webapp sync --devel

It seems pretty easy to be implemented in helmfile then!

Although if I had a webapp I would not have a separate release for mysql I would pin the version of mysql as part of the webapps chart.

By using umbrella chart? Sry if I'm not following you correctly, but I was thinking that you would have two release mysql and webapp. They both have versions. helmfile sync --devel would upgrade both mysql and webapp by adding --devel, which will also upgrade mysql to the latest available version of the chart, because it means --version >0.0.0-0 according to the helm docs:

--devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.

But if your req allows you to use a selector to limit sync targets, it wouldn't be a problem anyway.

[sstarcher]

I would use an umbrella in that situation if that was someone elses chart. If it was my webapp I would build it in as part of the chart itself for the webapp.

But yes I agree with your other statement about how it should function.

[mumoshu]

@sstarcher Do you still need this feature? I was wondering if you're basically going to follow @Stono's awesome pipeline, but utilizing your https://github.com/sstarcher/helm-release

[sstarcher]

I would personally still find this useful for development purposes. I think @Stono approach makes great sense for handling releases to higher level environments.

[mumoshu]

@sstarcher I agree with you that this is still useful for development purpose.

Also, along the lines of helmfile having momentum to support more options under releases:, I find it valid to add devel: true, so that you can selectively enable dev versions:

releases:
- name: myapp
  chart: myorg/mychart
  version: 1.0.0
  {{ if eq .Environment.Name "default" -}}
  devel: true
  {{ end -}}

Does it sound ok to you?

[sstarcher]

@mumoshu yep, makes sense to me and it would also be nice to have it at the global level of the helmfile itself. Similar to the args.