At work I have a monorepo with a bunch of helm charts in it.
The LCM for this repo is garbage - I wrote it a few years ago not really knowing what I was doing, but also knowing it was a temporary thing.
Turns out it’s not so temporary.

The company is looking to move to trunk-based development and I’m looking to redo the LCM of this repo.

Specifically this TBD: https://trunkbaseddevelopment.com/
We want to be able to say “we are doing this” and point at an industry way of doing things, rather than looking at something home grown or modified.

TBD makes sense to me, I’m pretty sure I understand it.

But- the charts on the repo are released altogether monthly (looking to change this, but anticipating another year or more before being able to do so), there are two breaking changes a year.

If I need to patch an old (supported) version, I might not be able to commit it to trunk and cherry-pick back to a relevant release branch because feature flags are hard to impossible in Helm (specifically in the way we use a library chart to provide 99% of the templating).

Am I “allowed” to commit/PR directly to the release branch in this case?
I know I technically can, but I can’t find what is idiomatic TBD in this situation.

#branchingstrategies #trunkbased #trunkbaseddevelopment #git #lifecyclemanagement

Do you experience missed release schedules, flawed releases that must be rolled back, and error reports from customers?

These are common problems arising from the same underlying cause (at scale).

https://buff.ly/6EgA85l

#mergeConflicts #atScale #branchingStrategies