Over a million developers have joined DZone.

Snap's New Branchable Continuous Integration (CI)

DZone's Guide to

Snap's New Branchable Continuous Integration (CI)

· DevOps Zone
Free Resource

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

Colleagues at 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:

H7785: 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

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs


Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}