Go isn’t another Jenkins, and that’s a good thing

ThoughtWorks announced that it was releasing Go as open source. Go puts into practice the ideas ThoughtWorks has been promoting for years, namely continuous integration and especially continuous delivery. Go itself is interesting from several angles. Plenty of CI servers exist, but nobody had offered a coherent approach to continuous delivery until Go appeared. A colleague aptly called this the post-Jenkins era. Go is built around the ideas and experience Jez Humble and David Farley describe in their book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

One size fits all vs. Lego

Jenkins has become the backbone of continuous integration at many companies because it's highly extensible. There's a whole range of plug-ins you can use to build practically any testing or deployment process on top of Jenkins. Jenkins and its plug-ins are a pile of Lego bricks you can build anything out of. If something's missing, you can write it yourself. With the Lego approach you get the pieces and have to put them together to get the features you want. Unfortunately, there are no “Lego sets” with just the tested pieces for a specific use case like continuous delivery. In theory, Lego lets you build anything. In practice, as we've found again and again at GoodData, doing so is expensive and the result is fragile.

You pay for putting those pieces together when you build and test the solution, and again when you maintain it. During development you first need to find the plug-ins that might cover your use case, see if they'll work together and then fit them together properly. Practically any upgrade to Jenkins or one of its plug-ins can make the whole solution collapse like a house of cards. You also need domain knowledge, such as how continuous delivery works. It's hard to build something when you don't know what you need to build.

Go's great advantage over Jenkins, to my mind, is that domain knowledge about continuous delivery and its basic concepts are built into the core. Go is extensible, so you can adapt it to your needs. Go makes sense to me because it presents itself as infrastructure for continuous delivery rather than another continuous integration server. Go certainly won't kill Jenkins. Companies will still use its Lego-like flexibility for their testing infrastructure and continuous integration.

If I were starting today on the platform we've been building to provide continuous integration and delivery at GoodData, described in The evolution of continuous integration infrastructure at GoodData, I'd build it on Go. It would have saved a lot of programming and a lot of work bending and tuning Jenkins for pipelines, artifact promotion, visualization and more. I have no experience with Go, and this particular implementation might not take off in the long run, but the concept is a step in the right direction. By the way, let me know if you'd be interested in working with Go.