Curious / recommended build strategy, update umbrella helm chart with source code change

Feedback & Ideas Tenzu
1

I used taiga for what seems like years. One thing was missing though, it didn’t have helm charts. Well, it did have helm charts, but the charts were written by someone selling a class who used the charts in the class and if you asked him about the charts he wanted you to pay for the class.

I checked in on tenzu now and then. I see it has helm charts. This time they look like they are 4 months old.

In my projects, when a change is made to source code a build is automatically triggered, containers are automatically built, then an umbrella helm chart is triggered which includes all the containers of the deployment. With development I use a SEMVER with a dash. This means to see the version with helm you have to specify ‘helm install –devel’. Additionally, I use ‘kargo’, a app created by Akuity which works alongside argocd to deploy out the umbrella chart upon being pushed. (Some folks might prefer to use ‘renovate’.)

This strategy causes the git repo to be updated with each build. Since the repo is showing 4 months ago, that tells me this strategy is not being used.

Philosophically, I know some folks would prefer not to update a helm chart each time source code is updated, but I would propose that with the ‘–devel’ parameter of helm, that doing so it something to consider.

This approach, would also mean that the latest “everything” is deployed to your test environment, always. So, whatever tests you have running, are always being run no matter what changes have been made.

I see some photos from conferences where the app has been advertised to the public, and I see there is a demo available to try things out, this approach works with a paid service … and I understand that’s probably the main goal, but if the app is to be available with an open source approach then helm charts need some love. From the outside, if ‘–devel’ isn’t being used, then we know that things aren’t being tested as the changes are made which lowers confidence (and breaks automation with folks who deploy the latest to their own testing before promoting internally).

2

Hi @lknite and welcome.

The helm charts we make available are the very same one we use ourselves for our deployments. When we prepare a release, we first deploy to a staging environment available internally, then after tests we deploy to our public demo so people can play with the new features. Only after this do we release a production version. All this is done using the same helm charts.
If we want to change the helm charts, we will test them internally before releasing them to the public but at the end of it you get the same files as us.

If the last update goes back it’s only because there was nothing new to add. And as a coincidence we did need to update them just today to fix something for our latest release.

For now, our helm charts use the “latest” image tag by default and we strongly encourage administrators to pin it to the version they want using the values file, update manually to new version and always use the last chart version when they update. I know this is not ideal and we do plan to add to our CI/CD a step to update the image tag and chart version automatically on each new release but this is not our priority right now since our roadmap is pretty full. And maybe one day we will also add an umbrella chart to make it easier to deploy the frontend and backend together.

About paid service, our SaaS is proposed using a free contribution model, so people can freely chose what they wish to pay us, if any, for the service we provide them. People that don’t want to use our SaaS can decide:

  • to host Tenzu fully themselves and chose whether to support us additionally with a donation;
  • to enlist the help of one of our official partners that can provide dedicated hosting, on-premise outsourcing, support, etc

We are not monetising the deployment recipes we provide and our business strategy is provided fully transparently. We give no strong guarantee on the docker-compose recipe in our docs since we don’t use it ourselves, but you can stay assured that the helm chart on the other hand is very much maintained and tested. We are open to being paid to prioritise specific feature if companies have a need for them though.

Feel free to ask if you have more question on how we deploy Tenzu :tenzu: !