Hacker News new | ask | show | jobs
by mr_tristan 2521 days ago
Oh yes. #1 problem I've experienced at multiple places: delaying integration with tons of branching.

Usually the PM or PO force everyones to using some vague "product version" they track for public releases. Places that use monorepos well tend to have very few branches (like, maybe 2 or 3), which have nothing to do with your public product versioning scheme, and instead use "branch by abstraction" to stay integrated.

But what I end up seeing, is that the product team and middle management gets involved with dictating version control, e.g., "this will be version 1.2, and then that should be 2.3, ok let's cut those branches...", and then they change their minds as some team has to delay and before another is ready. And then bugs start rolling in from both testing and they don't know what to do, and they start asking people to just "get it done", and then, things really start falling apart. You add 10+ teams trying to use branches for their own work based off of god knows what and it becomes a mess of crazy integration problems.

I seriously think that a huge benefit of multiple repositories, is that is scares the pseudo-technical managers and product people into not bothering with trying to track or dictate usage of the version control system.

2 comments

My experience is similar. The newly promoted CTO used a botched merge and delayed release to justify the move to a complex but half-assed monorepo branching strategy with minimal tooling and documentation, trashing any systems teams had in place. We've started botching releases, losing prospective clients, and now are in release limbo.
Or you could just tell them to stay off versioning/release/branching discussions, even in a monorepo. All they need to know is what release/deploy has what features, and when the release happens.
Easy to say when you're starting from scratch, but in all of my cases, these were "pre-existing conditions", i.e., was in place before I joined, and it took a long time to get people to see the light. It gets real tricky when you're _not_ a manager, and you're basically asking other managers to stop having such a loud voice in things.

Just another case of "culture eats strategy for breakfast". Once people start using any particular versioning strategy, it becomes canon, even if it's a terrible way to organize.

Yeah sorry if I came off as dismissive. It's usually a long process, if that's how things run.