[shosti]

Author here; yeah, helm is the part of our stack we’re least happy with tbh (it’s turned into a huge pile of templated yaml files for each project that seems like it might not be maintainable long-term). I’m curious about looking into kustomize, but the package management/rollback capabilities of helm are quite nice; is there a good “pre-baked” solution for that that doesn’t involve helm?

[markbnj]

Great article, thanks for writing it.

> I’m curious about looking into kustomize, but the package management/rollback capabilities of helm are quite nice; is there a good “pre-baked” solution for that that doesn’t involve helm?

Not that I'm aware of. I'm only really familiar with helm, kustomize and ksonnet at this point, and of the three only helm took the approach of running a server-side stateful thing that could take responsibility for pseudo-resources called releases. I haven't followed work on the next version closely, but it will be interesting to see what changes as they ditch the client-server architecture. I assume it will be more like terraform with some sort of state file.

Rollbacks for us basically mean go back and redeploy the last good ref. The pipeline is completely deterministic from the commit. The underlying build system that produced the container might not be, but we don't have to rebuild that since it's still sitting in the registry.

[mirchiseth]

Excellent write up, thank you. I was also looking to read on how the dev experience changed moving to k8s. Were they using heroku cli? Did you create an equivalent experience in k8s or adopted a new one?

[tjungblut]

I had some really good experience with ArgoCD so far, it is agnostic to what you're using as a configuration tool (helm, pure yamls, etc) and it just works and has a nice UI.