Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Do 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 🤡 -
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... -
@nibor what he said
Also if you have a queue that work goes through any improvement in efficiency that does not address the bottleneck in the queue does effectively nothing.
Google shift QA left -
Whatever 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...
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
Question about scrum in terms of developer/QA workflow. We have a problem in our team: basically when a dev submits an MR it needs to get 2 approvals from devs and then task is marked ready for qa. Now problem here is that qa takes 2-3 weeks to get to the task and when they do usually MR has merge conflicts and since QA are quite new-ish they have to wait for dev for conflicts to be resolved, ergo rendering the MR unable to be tested until dev resolves the conflicts.
Our teamlead proposes to solve this by forcing devs to rebase everyday (even if QA will get to working on the task 3-4 weeks later). Problem with that approach is that each conflict resolve removes approvals. So I had a situation where in 3 weeks I rebased like 15 times and 5 times I had resolve coflicts and because approvals were lost I had to annoy all devs and ask for reapprovals. And this is only with 1 MR. Now imagine all devs doing rebasing daily and spamming each other for reapprovals. Its not efficient.
Anyone could advice how to solve this issue?
rant
question