Skip to content

Provide an upgrade path from helm2 to helm3 with Auto DevOps

Problem to solve

As a platform engineer, in order to support both legacy and new clusters, I need support for helm2 and helm3 based deployments within Auto DevOps.

Intended users

User experience goal

Be able to deploy to helm 2 or helm 3, and provide an upgrade path from helm 2 to 3.

Proposal

See #221187 (closed) for much details

We should leverage the on-going work in gitlab-org/charts/auto-deploy-app#70 (moved) to make a "safe" breaking change release, so that new feature only go to the Helm 3 variant going forward, but the Helm 2 variant receives bugfixes and security updates until %14.0.

  • New users can get the Helm 3 version by default before %14.0,
  • Existing users stay on the last stable Helm 2 release until they opt-in
  • At %14.0, we do a one-time failing pipeline that informs the user that Helm 2 is fully unsupported (but they can still remain on that image)

If gitlab-org/charts/auto-deploy-app#70 (moved) does not allow the above setup, then consider an alternative

Further details

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references