mergeq comic explanation

I’m sure that you have never broken the build, but you have probably had to wait around while someone on your team scrambled to push up a fix for the build that they broke. If so, you’ve probably wondered how to prevent that from happening. Maybe you have strict rules about running tests locally before pushing or maybe you make people put a stuffed animal on their desk when they break the build. Regardless, there is a better way.

mergeq allows you to run all of your builds on your CI server, but only merge in the successful builds. This is not only great for preventing build breaks, but it’s also great for letting your build server do the work instead of waiting for your machine to run the build before pushing. This is especially wonderful if, like us, you have beefy machines running your build and they can run in 5 minutes what takes your machine 20.

mergeq is an implementation of the “pre-tested commit” pattern that is:

  • Robust–two people can merge at the same time and, as long as their branches do not conflict with one another, they both get a chance to get merged in safely.
  • Continuous Integration server independent–as long as your server has permission to push to your repo and can support running only one build at a time, it should work.
  • Flexible–there are hooks to support safety checks or post build notifications.
  • Easy to setup–no additional intermediary repository, no additional infratructure.
  • Battle tested–we have been using it for over 3 years with great success.

Take a look at the README for installation and usage instructions. There are currently only explicit instructions for TeamCity, but it should be easily adaptable to any other CI system. I know of one team using it with TravisCI at the moment. mergeq is designed to be used with git, but does not require github.