3 ms·

I don't get the hate for this at all. I wonder if it's because I've mostly mostly in corporate environments, with dedicated test/QA teams. One of the big advan

I don't get the hate for this at all. I wonder if it's because I've mostly mostly in corporate environments, with dedicated test/QA teams. One of the big advantages of either fixed dev/test/prod branches or dev/versionN branches is that the testers get a stable codebase to test against, which can have bugfixes applied without bringing everything else from dev along for the ride. It's virtually impossible to regression test a release if it has constant changes being made to it.

Pxtl 3y ago
Actually it was a poor qa/test relationship that destroyed git flow for me. Because the presence of release branches made the PO confident they could release any fixes or "emergency features" they wanted, they kept the QA team on the release branches while the dev team kept cranking through the backlog until it came time to validate like a year's worth of work and QA+PO threw up their hands and said it was too much to validate. So now I don't merge a feature unless I know it's allowed to be released. If it's not releasable, it's not merging.
morbicer 3y ago
Regression should be covered mostly by automated tests. We have a huge suite of e2e tests covering everything from frontend, through microservices, dbs, kafkas, mobile apps, pipelines. Over 8 years we added so much features that we would need to triple the QA teams every year, this simply doesn't scale well. We have dedicated QA people in full stack teams, they test features that are going to get merged and help with writing the automated tests. Trunk based development. We used to do it like you say. Non-stop issues with releases dragging, series of hotfixes, teams being torn between new features and firefighting something that should have been released already. Our velocity, quality and predictibility is soooo much better now.
- onion2k 3y ago
  We have a huge suite of e2e tests covering everything from frontend, through microservices, dbs, kafkas, mobile apps, pipelines. It's easy to advocate for a process that isn't git flow (eg TBD) if you have that. The problem is how to get from an environment without extensive tests to an environment with those tests safely without constantly having to fight fires everywhere. Saying something like "your git process is bad" or "feature branches are a waste of time" requires context. If you're in a situation where you need the 'safety blanket' of branches because everything is effectively untested then you have to fix that problem first. TBD works well if you have a robust, trustworthy environment. If you don't then it'd make things even worse.
- Yodel0914 3y ago
  That's quite interesting. We also have a huge suite of API integration tests, plus a lot of UI automation which does most of our regression. But we also have clients who are high profile enough that it's simply not feasible to push changes out without a human sanity-checking them first. We also have a fairly complex, interconnected domain and the system reflects that. I love the idea of having manual QA on feature branches being enough, but I'm not sure it's feasible for us.
Kwpolska 3y ago
Separate release branches do make a lot of sense and allow making only bugfixes to already released versions. The develop/master separation suggested by git-flow has no benefits and only makes a bigger mess. Trunk-based development also involves release branches, but is much easier: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
sanitycheck 3y ago
I used to use something like git flow, but the long-lived dev branch proved to be a real problem for QA because it changes constantly which led to tester confusion and wasted time. What I do now is keep master always release-ready and work is done in feature branches. The feature branches each automatially get their own (numerous) builds for testing, and internal QA is done against those. QA can be held up for weeks or months, so doing it this way keeps unfinished code out of releases and allows the business to change their priorities to shelve stuff that's suddenly not as urgent as it was last week - and also to suddenly do new surprise submissions/releases the day after randomly promising them in a phone call. If two feature branches have overlapping changes and it's taking people months to approve them then the merges are annoying, but usually sorted out in the lifetime of a single cup of tea. Release builds are done off tags, usually on master. Hotfixes to old releases (when there's no QA resource available to test a big update) can be done in a low-impact way by branching ("zombie/customer-platform-x.y.z") off the tag for that release, cherry-picking onto it and adding a release tag. Customers get demo/QA builds, also done off tags so when they get around to reporting an issue weeks later we know what code they've been looking at. (For context, the software is a client-side white label thing with different builds targeting multiple platforms - so there's a customer/platform matrix meaning many different releases, and almost every release has to be a manual submission each involving different 3rd-party QA which takes 2-6 weeks (best case, with no issues found). Config + content is dynamic, no two customers use the same subset of functionality. Keeping everything current is impossible.)

Pxtl 3y ago

Actually it was a poor qa/test relationship that destroyed git flow for me. Because the presence of release branches made the PO confident they could release any fixes or "emergency features" they wanted, they kept the QA team on the release branches while the dev team kept cranking through the backlog until it came time to validate like a year's worth of work and QA+PO threw up their hands and said it was too much to validate. So now I don't merge a feature unless I know it's allowed to be released. If it's not releasable, it's not merging.

morbicer 3y ago

Regression should be covered mostly by automated tests. We have a huge suite of e2e tests covering everything from frontend, through microservices, dbs, kafkas, mobile apps, pipelines. Over 8 years we added so much features that we would need to triple the QA teams every year, this simply doesn't scale well. We have dedicated QA people in full stack teams, they test features that are going to get merged and help with writing the automated tests. Trunk based development. We used to do it like you say. Non-stop issues with releases dragging, series of hotfixes, teams being torn between new features and firefighting something that should have been released already. Our velocity, quality and predictibility is soooo much better now.

onion2k 3y ago
We have a huge suite of e2e tests covering everything from frontend, through microservices, dbs, kafkas, mobile apps, pipelines. It's easy to advocate for a process that isn't git flow (eg TBD) if you have that. The problem is how to get from an environment without extensive tests to an environment with those tests safely without constantly having to fight fires everywhere. Saying something like "your git process is bad" or "feature branches are a waste of time" requires context. If you're in a situation where you need the 'safety blanket' of branches because everything is effectively untested then you have to fix that problem first. TBD works well if you have a robust, trustworthy environment. If you don't then it'd make things even worse.
Yodel0914 3y ago
That's quite interesting. We also have a huge suite of API integration tests, plus a lot of UI automation which does most of our regression. But we also have clients who are high profile enough that it's simply not feasible to push changes out without a human sanity-checking them first. We also have a fairly complex, interconnected domain and the system reflects that. I love the idea of having manual QA on feature branches being enough, but I'm not sure it's feasible for us.

Kwpolska 3y ago

Separate release branches do make a lot of sense and allow making only bugfixes to already released versions. The develop/master separation suggested by git-flow has no benefits and only makes a bigger mess. Trunk-based development also involves release branches, but is much easier: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

sanitycheck 3y ago

I used to use something like git flow, but the long-lived dev branch proved to be a real problem for QA because it changes constantly which led to tester confusion and wasted time. What I do now is keep master always release-ready and work is done in feature branches. The feature branches each automatially get their own (numerous) builds for testing, and internal QA is done against those. QA can be held up for weeks or months, so doing it this way keeps unfinished code out of releases and allows the business to change their priorities to shelve stuff that's suddenly not as urgent as it was last week - and also to suddenly do new surprise submissions/releases the day after randomly promising them in a phone call. If two feature branches have overlapping changes and it's taking people months to approve them then the merges are annoying, but usually sorted out in the lifetime of a single cup of tea. Release builds are done off tags, usually on master. Hotfixes to old releases (when there's no QA resource available to test a big update) can be done in a low-impact way by branching ("zombie/customer-platform-x.y.z") off the tag for that release, cherry-picking onto it and adding a release tag. Customers get demo/QA builds, also done off tags so when they get around to reporting an issue weeks later we know what code they've been looking at. (For context, the software is a client-side white label thing with different builds targeting multiple platforms - so there's a customer/platform matrix meaning many different releases, and almost every release has to be a manual submission each involving different 3rd-party QA which takes 2-6 weeks (best case, with no issues found). Config + content is dynamic, no two customers use the same subset of functionality. Keeping everything current is impossible.)