First question here (i'm usually on StackOverflow)...not sure if the right place (if not, please vote to move where it belongs).
If we have a dev process using traditional GitFlow approach, what criteria should be met before a Pull Request (PR) is opened? Specifically, if the work requires manual testing/QA signoff before being merged into master.
There are two sides of the fence here:
- PR's should not be opened until the work is "ready". (ready = ready for production, pending any code reviews, which should just be based on code quality/standards). Pros: reviewer doesn't need to check if the work is 'ready to be merged'. It's defined by the process. Cons: longer time (e.g waiting for test signoff) before the code is reviewed. PR's are open longer.
- Open the PR, even if it's not ready. Basically, allow the QA testing & code reviews to operate in parallel. Pros: code review and testing can operate in parallel. Cons: if issues are found in testing, the code needs to change, even though it has already been reviewed. So reviewing could happen multiple times, and communication needs to be fed correctly between parties.
Thoughts on either 2 approaches, or is there an option 3? What standards/advice is there in this process?
