Merge Queue Tools

Introduction

In small projects, there are typically a few developers and a few branches underway. As those branches reach readiness, depending on the flow of the project each developer may merge their own branches, or a tech lead may merge on request. Or sometimes they pile up (in a queue, conceptually) for review and merge.

But in large teams working (either a large single project or a monorepo) there can be dozens/hundreds/thousands of developers creating branches all the time. Many teams have the practice of doing a modest or moderate amount of work per branch, resulting in a large number of branches that must be merged to move the work forward.

To be merged, a change (branch) needs to be at least conceptually on top of the current mainline (regardless of whether a merge-commit or rebase strategy is used), and tests/lint/build/etc must pass. As each merge happens, the baseline moves forward – so the next candidate sometimes can’t be accurately tested until that point. At scale, this becomes the limiting factor in system progress: If the tests take 1 hour, the maximum number of merges you can do per day can be as low as 24.

Long before that limit though, having humans perform each of these operations is impractical, so teams typically adopt an automated system to queue up proposed changes/branches for merge. The function is roughly:

  1. Developers submit a branch as ready for merge, into a queue; often mediated by a human review and approval process.
  2. Automated merge system keeps picking the top thing in the queue.
  3. Rebase it on the current mainline.
  4. Test, Lint, Build, etc.
  5. Hopefully, merge.
  6. Repeat.
  7. When a change fails to re-baseline / merge / test, notify the developers working on that branch, they will need to resolve either a syntactic or semantic merge conflict and resubmit.

Of course there are strategies to increase parallelism; the process remains conceptually serialized but practically parallelized.

  • Related or unrelated branches can be combined and tested + merged as a group.
  • Use a build system that has a great understanding of what subset must be re-tested for a given set of changes.
  • Pre-build each candidate on a recent baseline, to pre-populate a build cache; a well-crafted build process (with Bazel or other tools) can safely optimize away some of the rebuild-everything process.

Some Tools

Here are some of the available merge queue tools – but many organizations create an internal merge queue management system.

For now, use of an automated merge queue remains mostly a marker of large-team big-tech-co needs; over time I expect it to be a routine in-the-box tool almost as common as CI.

Google’s Go language

Google’s Go language (“golang”) was first released in early form in 2009, and reached 1.0 in 2012. Go has matured quite quickly compared to many other new languages. We find several aspects of Go appealing:

  • Go is a pragmatic language, with features chosen to ease and speed development of substantial projects.
  • Go uniquely combines a rapid cycle “scripting” language feel with a robust static compilation process.
  • Go’s compiler generates statically linked binaries; this is very “old-school” in 2015, but static compilation trades off disk space (which is cheap) for simplicity and reliability in production (which is valuable).
  • It is suitable for both small and large teams, although our work so far as been small.
  • Go has good support for concurrency, well-suited to software that scales up to run on many core machines.
  • Go has proven relatively easy to learn, for developers coming from a wide variety of backgrounds.
  • Go has a good standard library.
  • Go can target multiple platforms, yet does not use a separately installed runtime.

Go Development at Oasis Digital

Oasis Digital has made use of Go for various small systems, including:

  • Experimental programs
  • Development by interns in our intern program
  • Utility software, test-stub software
  • Minor customer work

We recommend considering Go for certain types of projects:

  • Small, standalone software for which static compilation will ease deployment and support.
  • Data services behind front-end web systems, suitable for local or cloud deployment.
  • Applications where the Go concurrency model (“CSP”) is especially appropriate.

Grid Components for Delphi

This list of Grid components available for Delphi. is originally from a Usenet post by Anthony Richardson (anthony_r at sageautomation.com). I’ve added more since then.

The following is a list of Third-Party Grid suppliers:

SpreadSheets:

TAdvSpreadGrid – http://www.tmssoftware.com/
TSpread – http://www.jt.w1.com/products.htm
TSpreadSheet – http://www.uniyar.ac.ru/~dimak/delphi/spread.shtml
THyperSpreadsheet – http://www.pablop.demon.co.uk/

Non-DataAware:

InfoPower – http://www.woll2woll.com/infopower/
Top Grid – http://www.objectsight.com/
TAdvStringGrid – http://www.tmssoftware.com/
TStringAlignGrid – http://www.hoerstemeier.com/
(Free)
TSMTableGrid – http://www.sunsoft.ru/
THyperGrid – http://www.pablop.demon.co.uk/
TCoolStringGrid – http://www.cooldev.com

Data Aware:

TDBAdvStringGrid – http://www.tmssoftware.com/
QuantumGrid – http://www.devexpress.com/
InfoPower – http://www.woll2woll.com/infopower/
TOPAZ – http://www.softsci.com/topazd.htm
Top Grid – http://www.objectsight.com/
DbAltGrid – http://www.dbaltgrid.com/
TIB_Grid – http://www.ibobjects.com/
TDBGridPro – http://vipper.downloadit.gr/
TSMDBTableGrid – http://www.sunsoft.ru/
X-DBGrid – http://republika.pl/kszyszka/x-files.html
TExDBGrid – http://www.gjl-software.co.uk/
TVizDbGrid – http://www.vizacc.com/i_prod_gexpert.php

Grid Print Engines:

PrintDAT – http://www.grebarsys.com/
ExpressPrinting System – http://www.devexpress.com/
My (Kyle’s) own grid print engine, developed just before these started coming out.

Header Footer Add-ons:

DbHdrCtrlGrid – http://www.dbaltgrid.com/
TSDBGridFooter – http://www.sedlan.com

Specialist Grids:

TIB_Ledger – http://www.ibobjects.com/