Introducing the Merge Queue

Summary

Shopify describes a merge queue added to Shipit to reduce failures in its large monolithic Rails application, where growing pull request volume made manually checking whether master was safe unsustainable. The queue adds pull requests from GitHub, merges them when master is healthy, waits for required CI statuses, and can reject stale branches using configurable divergence thresholds. It is encouraged rather than enforced, while changing the browser extension’s visual emphasis helped make queued merging the default workflow; over 90% of core application pull requests use it. Shipit also handles unsafe deployment commits by allowing explicit marking and automatically detecting reverts of undeployed commits, marking the original and intermediate commits unsafe. These changes let deployment continue safely around reverted work without requiring developers to manually unlock the pipeline.

Takeaways

1. 1

   The merge queue waits for pending CI and merges or rejects a queued pull request instead of ejecting it and requiring manual re-enqueueing.

2. 2

   Configurable thresholds let Shipit reject pull requests whose branches have diverged too far by age or commit count.

3. 3

   When Shipit detects a revert of an undeployed commit, it marks the original commit and intermediate commits unsafe for deployment.

FAQ