Back to top
Chess - Chess piece

Here at Detroit Labs, we’ve devised a simple workflow change to reduce the amount of bugs merged into Main, leading to a higher quality app and a ton of other benefits. We call it QA Owns Main, because your project’s QA owns merging PRs into the Main branch. In the past, once a feature was coded it would go through code review and then be merged into the Main branch before passing to QA. While working on a challenging project, we came up with a way to ensure our Main branch had fewer bugs by waiting until the branch passed QA before merging it into Main.

Why is this a better practice?

  • The Main branch has fewer bugs, so new branches off of Main also have fewer bugs.
  • Demoing to a client is easier. There’s no need to determine which branch to demo from — it’s always the Main branch. Plus, everything that’s demoed has been tested, so there’s less chance to show the client bugs. We look more professional and build greater trust with the client over time.
  • Developers don’t have to disrupt their coding time to send a build to the client.
  • The project manager can easily distribute the Main branch to the client.
  • Developers have more confidence. It’s scary to merge an untested branch into Main; they don’t have to worry about breaking the app.
  • QA can leave bug reports as comments on the GitHub PR. This way the developer can see notes from code reviews AND QA testing in the same place. They don’t need to manage both GitHub and Jira once the feature has cleared code review.
  • Leaving a bug report as a PR comment makes it really clear that the bug is related to a specific build and not a prior build. Imagine if the Main build had 5 PRs merged in the past two hours. If the QA finds a bug, it might be tough to know which PR caused it.
  • It’s easy to implement. You can start tomorrow, mid-project, and it’ll probably take less than an hour to explain to your team and set up your CI.

What are the weaknesses of QA merging into Main?

  • This strategy could cause more merge conflicts because some PRs are merged into main while others are waiting to be tested. As a PR waits, it becomes more out of date with main and more likely to have conflicts. Often, a QA can fix this on their own by updating the branch in GitHub, but sometimes the conflicts are too severe and the developer has to resolve them. This could cause more work for the developer.
  • It can be unclear which build is related to which PR. Under the old method, a QA only had to download the latest main build and all new features were testable in the same branch. This can be resolved by automatically labeling builds with their PR number when they’re distributed through CI.
  • This method can be more time-consuming. You need to update branches frequently and building a branch can take as long as 15 minutes. Also, you can only test one feature per build. In the prior method, you could test all new features at the same time in the latest version of Main.

Overall, we’ve found that both developers and project managers love QA Owns Main. It leads to a higher quality app and the benefits outweigh the challenges.