Over the years people have asked about breaking Helm up into a set of smaller tools. For example, one for templating, one for application metadata, one for packaging bundles up, and so forth.
To understand why Helm doesn't break things up, which is a lesson for other projects as well, let's look at an analogy...
Kubernetes is one of the hot technologies in cloud. But as many have learned, chasing after the hot technologies does not equate to more cost effect infrastructure, happier developers, or a better overall cost structure. I'm aware of numerous cases where making a change ended up costing more without seeing gains elsewhere leading to a worse total cost of ownership (TCO). This is exactly the kind of situation business decision makers want to avoid. Just because technology is hot doesn't mean it's useful.
With that in mind, let's take a look at the business case for Kubernetes including being a little honest on the rough spots that could have a negative impact.
Public clouds are growing at a tremendous rate and many are moving at least some of their workloads to the public clouds. As I use these clouds – the plural being intentional - I continue to see more and more I would like out of them. This post contains two from that list with some details. I hope I'm not the only one looking for the same things.
On the Helm charts project the maintainers occasionally use the GitHub UI to make quick changes to a pull request. This is typically to fix something in a README file or to increment a version. We are trying to help contributors who make minor typos, are not native english speakers, or who run into version immutability collisions.
When Helm moved to a Developers Certificate of Origin it meant those little changes made in the GitHub UI now needed a DCO signoff to pass. Remembering to add that and what exactly to type is a bit of a pain.
So, Scott Rigby who is one of the charts maintainers went and made a browser extension for that. It runs in Chrome and Firefox. Once installed you go to the preference to add you name and email address. After that the GitHub UI commit screens will have the DCO signoff pre-filled for you.
If you deal with DCO signoffs and the GitHub UI there is now an extension for that. Thanks Scott.
When Helm moved from a CLA to a DCO it meant I needed to start adding a signoff to my commits on that project. While git makes this almost easy, by using the --signoff flag, it means I need to remember to use the flag when committing.
To make it easier I created an alias so I can use git cs and it will commit with signoff.
To create the alias I ran the command:
$ git config --global alias.cs 'commit --signoff'
After that, I had an alias I could use when using a signoff.