[flagged]
[flagged]
huttis? you mean like jabba?
Trunk-Based Development
71–80 of 108 posts
Re: Trunk-Based Development
#72I like TBD. I've always found the difficulty was in getting people to use feature flags, and then also managing those flags.
Re: Trunk-Based Development
#73No thanks.
I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced.
The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation someone gets themselves into.
Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
Re: Trunk-Based Development
#74No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation…
P.S. sitting down and learning git was probably the single most useful activity I've done on my 23 year career as a dev.
Re: Trunk-Based Development
#75We’re considering this at my org. We’ve got a distributed backend with about 2 dozen repos, with a big web of dependencies between them. When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects. Using trunk would resolve it, but would also of course introduce other issues.
Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together. When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components…
> When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
Re: Trunk-Based Development
#76No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation…
> the absolute hell of trying to find where a bug was introduced
What does this have to do with a trunk based branching strategy?
> Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
I'm fairly confused by this, as it doesn't seem to contradict OP, which is about using git...
Re: Trunk-Based Development
#77Earlier quoted context omitted.
I think their point is more that the usable scale of teams/codebases is not limited by trunk based development. Which that is pretty ample evidence of.
I get that. But aren't we all struggling with complex branching strategies and microservices, because someone told us "that's how Facebook/Google is doing it!"? :D
Probably not, because neither of them have complex branching strategies
Re: Trunk-Based Development
#78Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
It’s still trunk based development even if a feature branch / tag is created that will match production.
I'm convinced that development and operation (deployment) should be thought of separately. The branching model for the code should only serve the purpose to create a working product (artifacts of some kind). Those artifacts should be versioned (can be semver, or just the short hash of the commit, or anything else).
Once something is ready for deployment it can be deployed, in the best case this is just clicking one button or one CLI command.
Developers shouldn't be afraid that one wrong commit can automatically just go to production.
Re: Trunk-Based Development
#79No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation…
> deal with them losing work
The fact that is ever possible is a damning indictment on Git
> Git is actually simple
The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple.
Things that are actually simple don’t require a never ending stream of guides and tutorials.
The world can do much, much better than Git.
Re: Trunk-Based Development
#80Earlier quoted context omitted.
Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together. When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components…
> When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again. While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact wi…
I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.