Go as continuous delivery tool for .NET

http://simon-says-architecture.com/2014/02/28/go-as-continuous-delivery-tool-for-net/

Following my previous post regarding a possible design of continuous delivery scheme for an ISV, I’d like to focus today on ThoughtWorks Go. This tool used to be quite expensive but just a few days ago ThoughtWorks made it completely free and open source (under Apache 2.0 license). Because of this dramatic price drop I thought that I would give Go a second chance as try to replicate the same stuff I did with TeamCity. Let me share my insights after spending few days with Go.

Name

The name is probably Go’s biggest problem. It is absolutely impossible to google for any information regarding it. Try ‘NUnit Go‘ for example. Really, these days when choosing name for a product one should think about it’s googleability.

Installation

As we’re a .NET shop, I installed Go on my Windows machine. It was quick and easy. Good job here. Same for installing the agents.

Documentation

Go’s docs are very clean and nice but I have an impression that there’s more chrome than content in them if you know what I mean. Take NUnit integration for example. The only thing I found was the information that Go ‘supports NUnit out of the box’. It turned out that by ‘support’ they mean it can process NUnit’s TestResult.xml file and display ugly (yes, I mean very ugly) test summary on release candidate details page. In order to generate this file I need to run NUnit on my own using the task ‘framework’ (more on that later). Of course I need to install NUnit runner on the agent first.

By the way, there is quite a lot of video how-to’s but personally I don’t think that’s what devs are looking for. On the good side, the HTTP API is very well documented.

Last but not least, I have a feeling that Go’s docs lack transparency a bit, especially compared to Octopus. I mean things like what is the protocol between the server and the agents and why it is secure should be better explained so that I as an ISV can use them to convince my clients to using Go.

Pipelines

Go has a concept of pipeline which lets you define complex build and deployment workflows. Each pipeline has one or more stages executed sequentially, either automatically or with manual approval. Each stage consists of multiple jobs which can be executed in parallel on multiple agents. Finally, each job is a sequence of tasks.

To add even more possibilities, pipelines can be chained together so that completion of one pipeline kicks of another one. Pretty neat. I really like it. The sequential-parallel-sequential design is clean and easy to understand and is expressive enough to implement complex processes and constrained enough to not let these processes become a pile ugly spaghetti.

Agents

Go’s agents are universal. They can execute any shell command for you and pass the results back to the server. They have no built-in intelligence like TeamCity (build-specific) or Octopus (deployment-specific) agents and can be used for both building and deploying. Plus they are free. Good job.

Tasks

Tasks are in my opinion the second biggest (just after the name) failure in Go. A task can be either Ant or NAnt script or… any shell command you can imagine. While I appreciate the breadth of possibilities that come from being able to execute just anything, I really don’t like the fact that I have to do everything myself.

Do you, like me, enjoy TeamCity’s MSBuild configuration UI? Or it’s assembly version patch feature? Or maybe it’s visual NUnit runner configurator? Nothing like this here. To be fair, there is a concept of command repository which allows you to import frequently used command examples but it really isn’t something comparable to TeamCity.

What surprised me is that there seem to be no plug-in system for tasks and for sure no lively plug-in ecosystem. I would expect that if ThoughtWorks made a decision to focus on workflow and agents (which are really good), they would publish and document some API that would allow people to easily write custom task types as plugins. For example, if I would install NUnit plugin into my Go, I would expect NUnit runner to be deployed automatically to my agents.

Summary

I managed to build a simple pipeline that does build my source code, packages it up into NuGets (using OctoPack) and runs the unit tests. It’s for sure doable but it’s way more work compared to TeamCity. Because I don’t like a role of release manager who owns the build and deployment infrastructure and prefer teams to own their own stuff, I made a decision to drop Go and focus on TeamCity. It is much friendlier and I don’t want to scare people when I am helping them set up their builds. If ThoughtWorks or the community that will probably form around Go gives some love to defining tasks I will consider switching to Go in future. Go is definitely worth observing but in my opinion, for a .NET shop it is not yet worth adopting.

To be fair, TeamCity is not a perfect tool either. To be able use it we have to overcome two major problems

• No support for defining deployment pipelines (everything is a build type). Bare TeamCity lacks higher-level concepts
• While TeamCity’s base price is reasonable, a per-agent price is insane if one wants to use agents to execute long running tests (e.g. acceptance)

More on dealing with these problems in following posts.