Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
zlice391250dscript the rebase for qa, help get qa up to speed
skip the approval bs and tag "ready for qa" and have them work off that ?
nibor518450dIf it takes 2-3 weeks for QA, who are presumably members of the scrum team, to review a story, then you have some fundamental problems with your whole interpretation of scrum.
vBitza15950dDo you work in sprints? You could implement a develop branch per sprint, all PRs go to the develop branch after dev review. When QA gets to finally test it you'll merge the develop branch into master after they mark it as passed.
And if QA is more than one sprint behind dev you could branch the next develop branch on the previous one... But it might create a mess when a dev needs to integrate a fix to an older develop branch...
But anyway it's a starting point..way better than everyone rebasing all day everyday 🤡
MR is immediatly merged, and QA starts immediatly.
If QA has a backlog, All Devs stops creating more work for QA by writing automated tests, until QA backlog is cleared. Then normal workflow can be restarted.
If you have a workflow and the workflow doesn't work because the necessary human resources are missing....
... Burn the fucking workflow.
I mean it. Don't work around, don't try to be smart, just nuke it.
The workflow needs to fit the human resources given.
In this case it's pretty evident that the problem lies in the verification phase… so do the sane thing and give QA a sensible timeframe to check the merges.
This could be - as some pointed out here - by properly releasing in a periodic interval.
Alternatively you could just do an additional branch, queuing up all changes - or utilizing tags / commit IDs.
One of the reasons many projects fail btw is this - copying a workflow without validating that it fits.
It's an entirely different game wether you have 2 devs, 1 qa guy or 50 teams of 5 devs and 20 qa teams of 3 devs...
Workflows can only solve problems if they're not the problem themselves...
Oktokolo762350dWhatever you do - never ever leave completed features just rot away in abandoned branches. Until they arrive in the common staging branch, some dev has to rebase them every time something significant gets merged into staging. If for whatever reason the dev who did the feature should not be bothered to keep his feature branches rebased, you need to have someone else responsible for the daily rebase and other maintenance of all that branches until they finally get integrated into staging. That doesn't have to be a dev. But if it isn't a dev and conflicts appear, that poor sod better has access to a dev...
Oktokolo762350dBut if QA testing is lagging behind, there has to be a reason for that. And it has to be fixed. Because in the end, fetures will wait years until they get tested. And that isn't gonna work at all. So either make devs automate more of the testing or get more QA people.