Snap’s new branchable Continuous Integration (CI)

Colleagues in ThoughtWorks Studios have just released a version of Snap-CI (last night) that automatically commissions pipelines if a branch is pushed up into Github. A popular way of working with Git means that developers will make a branch for a feature that they are working on, in advance of merging that back into the master (when complete). Snap-CI is watching for the creation of those branches, and if the master is configured for a pipeline itself, will automatically create the pipeline around new branch. It will automatically decommission the pipeline if or when the branch is deleted. It does not matter whether the branch deletion is because it has been merged back in to the master, rather than work that’s been abandoned of course. Great work Badri and gang!

I muttered about branchable CI before of course, though a slightly different design.

Un-Integrated Work Costly in Itself

Lean Manufacturing teaches is that it inventory building up at any system that can be represented by a Pert Chart is inherently costly. That’s why the industry builds CI infrastructures that are able to handle peaks of commits into a mainline/trunk/master. You don’t want a delay between the commit/push and the news that it was bad, as you fear (Lean again) a “stop the line” event that’ll take a while to sort out in the worse case scenario.

As an aside, take a few mins to see a flash animation of bottlenecks and Lean Manufacturing. Can someone make another version of this before it falls off the web?

Git’s Branching Model and These Pipelines

Git makes this easy, and Snap-CI is all about maximizing you Github workflow specifically. With Git, all branches are essentially from root:

PH7785: ls -al 
-rw-r--r--@   1 paul  wheel   4002 Sep 16 17:18 bar.rb
-rw-r--r--@   1 paul  wheel   4286 Sep 19 11:32 baz.rb
PH7785: git checkout my_featurebranch_12
Switched to branch 'my_featurebranch_12'
PH7785: ls -al 
-rw-r--r--@   1 paul  wheel   4002 Sep 16 17:18 bar.rb
-rw-r--r--@   1 paul  wheel   4286 Oct 22 08:49 foo.rb

This would be harder to do with Subversion. The reason being that branches are not all from root, and while Svn has a trunk/tags/branches ideal, you don’t have to follow that. A CI tool would have to be able to work out where the logical root of a source tree (and build scripts) were in order to be able to do it’s business