queueing-prs.md

Queueing PR's

Once a PR is next in line and ready to be merged (all code review is finished and QA has signed off) the developer should locally:

Update Feature Branch

$ git fetch --all
$ git rebase -p upstream/integration integration
$ git push -f origin integration
$ git rebase -p integration feature_branch
$ git push -f origin feature_branch

• If your team develops against a branch other than integration you can replace integration with that branch.

Perform some light QA and smoke testing

The developer should then check to see if there is any regression to the feature or defect fix they are trying to introduce into upstream/integration, 'a white screen of death' or any other errors. Once the developer is satisfied with the state of the PR they can then notify the team that the PR is ready to be merged.

Benefits of queueing PR's:

• promotes team communication, collaboration and knowledge sharing
• introduces an additional 'tight' feedback loop
• guarantees a linear Git history (makes debugging and using git-bisect more 'human-friendly')
  • not this
• provides an opportunity to catch any regression before it enters into a shared history
• no extraneous merge commits in PR's (there have been some PR's where the majority of the PR were merge commits)

From my experience this has worked flawlessly. There has always been a very slight sense of velocity loss but the discipline and rigor helped avoid unnecessary bugs or regression being introduced into our shared history and has undoubtedly saved time in the long run and made the teams I was apart of more efficient.

Examples where this would have been beneficial

• DE17693
• DE17690

These are two of numerous examples where regression could have been avoided if PR's were queued.