I’m new to Octopus and trying to setup release pipeline in Octopus for our Kubernetes application.
We use Helm and publish every new release of our application as Helm Chart into our own Helm repo.
So for example, we’ have MyApp Helm chart with version 1.0.0 published into Helm repo. And we create corresponding Octopus release for each version of the Helm chart. Hence we have Octopus release 1.0.0 created, pointing to MyApp chart version 1.0.0. Such release contains single Upgrade a Helm Chart step. So far so good.
I’m looking for recommendations / best practices on how to organize releasing of environment-specific and tenant-specific settings (stored as Helm
Let’s say we have 3 environments: Dev, Test, and Prod. And we have N tenants in these environments (couple of mock tenants in Dev and Test, and hundreds of actual tenants in Prod).
We’d like to store environment/tenant specific
values.yaml in a separate Git repo and update them as needed (e.g. enable/disable features, scale replicas, etc).
I know that Upgrade a Helm Chart step allows choosing values from “Files in Additional Packages” but these additional packages seem to be snapshotted at the release time.
So what would be the workflow if I want to edit some environment/tenant specific setting?
I can push updated values as new version of the settings-only package to Octopus built-in feed, but how do I re-deploy the same Helm chart (i.e. the same Octopus release 1.0.0) using newer version of the settings package?
PS. Side question - I wonder if Octopus support offer meetings to discuss such types of questions online?
Thank you in advance!