Snap-CI is configurable to test every active branch, on first commit/push - https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-p...
Of course doing that will expose problems that lead the dev team to reconsider Trunk Based Development.
99 karma · joined January 10, 2014
Snap-CI is configurable to test every active branch, on first commit/push - https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-p...
Of course doing that will expose problems that lead the dev team to reconsider Trunk Based Development.
Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/
Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, and have processes that are less lock-step than what they do in-house.
Android - Samsung, on each release (maybe not anymore), used to check all the composite parts of Android into one big trunk for themselves. Back into their Perforce.
> If you're making Google Chrome, you don't.
There's nothing stopping the Chrome team from doing Trunk Based Development on Github, and accepting unsolicited pull requests like any other team.
Trunk Based Development is also "all work in feature branches that live for less than a day or two". One small difference to Github-flow though: https://trunkbaseddevelopment.com/alternative-branching-mode...
Subversion having that TBT thing made it easy for people to respond 'yes we're doing trunk based development' when they're not
Developers, if they are local branching, are not marshaling long running 'in progress' changes there. By habit they're working on something that's going to hit the trunk after a matter of hours or a day or three. They might flip to a new branch for a defect fix (and push that), before coming back to the thing they were working on.