4 ms·

Regression should be covered mostly by automated tests. We have a huge suite of e2e tests covering everything from frontend, through microservices, dbs, kafkas,

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.

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.