Go (the ThoughtWorks one): Interview with Jez Humble
•
In response to a recent article, I spoke to Jez Humble about Go:
Me: Who are you, and what do you do for Go?
Jez: I wear a couple of hats: I am product manager for Go: ThoughtWorks Studios' CI and release management platform, and I also talk a lot about how to deliver software. I recently co-authored a book called Continuous Delivery with Dave Farley that has beenvery well received
Me: What happened to Cruise? Why the name change?Jez: Well when people heard "Cruise" they almost always thought "CruiseControl". But Go is a different beast - it's built from the ground up to be a platform for continuous integration and release management that provides visibility on the production readiness of the system to everyone involved in delivery - not just developers, but testers, operations people, managers. With the release of Go 2 it also scales up to even the biggest organizations, unlike Cruise, which was essentially a workgroup level product. For example Go 2.1, which we just released, allows you to provide CI as a service - you can control who can access which boxes at the server level, but projects can be granted administration rights over their own CI configurations, even if they can't trigger or even view other projects' builds.
Me: Reading the Go website, it's clear that you're going after deployment in a big way. For example, you need to read up to see that it does Continuous Integration. The Build Pipeline has been renamed to Deployment Pipeline. Is this a deliberate strategy to deprecate Continuous Integration and promote the newer meme of Continuous Delivery, and are you leaving the market for development-only tools alone?
Jez: Well, I should say that we always called it the deployment pipeline, both in the book and in Go. Of course "build pipeline" was always a commonly-used variant within ThoughtWorks. But yes, you're right that we are trying to focus holistically on the problem of delivering software, not just on the development space. So continuous integration is still important, but - as the DevOps movement correctly asserts - unless you work to change the rest of the organization, and in particular the relationships between development, testing, and operations, you're not actually going to see the results that you want to. In most places, the main delivery risk isn't in getting the software dev complete, it's in the "last mile" from dev complete to release.
I wouldn't say we're leaving the development space alone: we have Go Community Edition, which is free to download and use, and offers some really powerful tools that none of the other free products have. For example there is built-in test reporting that lets you throw a bunch of automated tests at the build grid and tells you which ones are currently broken, which check-in broke each one, and who was responsible for that check-in - i.e. what's broken and who broke it. We're going to continue adding stuff to the Community Edition to keep it the best possible tool for developers, based on our own experiences dog-fooding it - we upgrade our own Go system with every good build.
Me: Another vendor made the point that their competing product was able to accommodate many kinds of project, while Cruise is more prescriptive. Is he correct? And which of accommodating or prescribing would be a feature, in any case?
Jez: In every tool there's a trade-off. So while "prescriptive" vs "flexible" sounds like an obvious win-lose, there is a cost to optimising for flexibility and not making any prescriptions. Go has a unique model which is optimized for modeling your organization's value stream from check-in to release, so you can visualize, trace, and control the flow of builds through that value stream. We excel at that, and we don't really care what your value stream looks like - in that respect, Go is extremely flexible, and you can have manual steps where you haven't automated stuff yet. But it gives you a unique and incredibly powerful view into your delivery process that really facilitates collaboration between dev, testers and ops (see this video from the people at MoneySupermarket), and makes it much easier to find out where the bottlenecks are in your process.
The classic process-chaining model that the other tools follow is very flexible, but it's hopeless at getting any idea of the bigger picture of what's going on in your organization, or seeing where a particular build went, or tracing back from a particular deployment back along the process it came through and who touched it. As a result of its model, Go is somewhat opinionated about how you do things. For example it expects you to promote binaries rather than source code. But I believe that's a good thing - the tool should make doing the right thing easy. In practice you can model any sensible process with Go, and once people grok the model, they invariably love it.
Me: What's your strategy for 2011? Will you be attempting further integrations with Twist and Mingle, or adding any new tools?
Jez: We don't plan to launch any new tools - our hands are pretty full with the three we have. But yes, we will be working on tighter integration between them. Go and Mingle are both becoming OpenSocial enabled. Go 2.1, which just came out, has a pipeline widget that can be hooked into Mingle 3.3, which is just about to come out, and in Go 2.2 you'll be able to see the Mingle card activity - fixed bugs, completed features - between two deployments.
Go is also now far enough ahead of the curve that in 2011 we'll be pushing out some oft-requested features that aren't differentiators, such as clicky admin for UI, support for more version control systems via a plug-in API, and various other bits of integration with the wider tool ecosystem. We also have a bunch of other, more innovative stuff planned that I am going to keep secret for now - we intend to retain plenty of clear blue water between ourselves and the competition.
Me: Now that ThoughtWorks uses Go in the field, do you get many feature requests from ThoughtWorks developers?
Jez: ThoughtWorks developers are our harshest critics - far more so than our external customers. Once you've developed a skin as thick as mine this is an invaluable asset, because you know if you can make them happy, you're going to really delight your other customers. We've made a sustained effort to engage with ThoughtWorks projects from the beginning of Go's development, and it's really paid us dividends. We are running on huge, distributed projects with over 100 developers and enormous build grids, and a lot of our requirements - functional and non-functional - come from them, because they're at the bleeding edge of what's possible with Agile and Lean
methodologies.
Me: Finally, can you name one feature of Go that you believe to be unique?
Jez: We have two !
First, Go is also still the only product that fully supports deployment pipelines. These let you model your delivery process from check-in to release, and provides visibility and traceability into the movement of inventory, in the form of builds, through your build, deploy, test and release process. They also give team members control over the process, allowing them to self-service deployments into the environments of their choice.
Second, our test analysis stuff. Throw a bunch of tests at the build grid, and Go will collect the results, analyze them, and tell you exactly which tests are currently broken across the whole suite, which check-in broke which tests, and who was responsible for the check-ins. In 2.1, you also get the stack trace and the check-in comments at the click of a button. This is a game changer with large suites of automated tests, and nobody else does it. Supports any tool that outputs junit-format test result files, including junit, nunit, Ruby test/unit, and Twist. I've attached a screenshot.
Sounds like they've come a long way from CruiseControl. I'm talking to another vendor soon.