| || |
GIT (and gitflow, github flow etc) and the Pace of QA Question
Quick question that goes more into a dev / qa balance but here goes.
We are currently using GitHub Flow with one master branch (though this could apply for any number of git based flows). The problem we are having is that the QA is getting "behind"
Behind is in quotes because we are doing our job and finishing the commitments in time. But the issue is coming from the developers having to remerge and run their ci's as their branches are getting more out of sync with master. Basically even if we finish the testing before the end of say a 1 week sprint. The developer is busy updating all their branches everyday if necessary.
The only way to really combat that directly is just hire more QA to get branches processed at a higher rate. I don't feel like that is the best use of QAs time to almost finish testing faster due to an issue that relates to the developer flow.
I love git flow. But one of the weaknesses of gitflow is if a developer keeps a feature branch alive too long, you run into stale code issues. Ideally you'll want to use a CI system that does automatic merging. So code flowing upstream makes it to all the child branches. For example, say a hot fix was applied to production, you want that to flow back up to the dev branch so that stays in sync, then that flow back up to the feature branches.
Originally Posted by Okami
This will force the developers to handle merge issues early on and prevent their feature branches from going stale.