This message was deleted.

Hey Daniel, great question! I think it was a bit of both tooling and how we used the tooling. The fact that we pulled together multiple tools and then added a lot of our own custom templating on top of it made it slower to iterate on the system we built which in turn made it harder to change how we used the tooling and the processes in place. We are currently in the process of moving to helm to replace this more custom template setup. Part of the reason is because helm is better known/more industry standard/easier to look up documentation but a huge part of the focus on moving to helm is also changing the processes around our templating. For example, we are establishing guidelines for creating charts, including making sure every input field has a default, trying to minimize any schema-breaking changes. Another thing we’re focusing on is what do the application developers need to see (i.e. the chart users) vs what do the platform developers need to see (i.e. the chart creators). In our old system, the final kubernetes manifests are generated in the same repo as the application developers’s inputs to k8s resources and their application code, which generated a lot of noise in their PRs so we’re rethinking this as well.

@Reynis Vazquez-Guzman valuable insights! Thank you very much for taking the time to answer my question! We are also on the way to provide some platform capabilities on top of Helm. I think it is totally doable but as you also described it is sometimes hard to find the right layer of abstraction without blocking all means for user flexibility.