Five Hours with ThoughtWorks Go


After a day of looking after a sick child I had won enough brownie points to get a few solid hours of geek time on my computer. It’s the first time I have used my PC in anger since I installed Bias Lighting after reading Jeff Atwoods post earlier this month ( I bought the Antec Halo 6 LED Bias Lighting Kit and placed it on the back of my middle monitor. Two weeks later the lights have fallen off and are now doing a great job of lighting the floor underneath my desk.

But this is not a review on back lights; it’s a review on Thoughtwork’s agile release tool “Go”.  I believe it the reincarnation of Cruise Control, remember cruise control? I do, and I never liked it. Once I discovered TeamCity I was hooked and have never looked back.

However TeamCity is a build tool. It compiles code. It doesn’t care what you do with it, it doesn’t care about when you deploy, it doesn’t care about your team structure, it doesn’t care about release notes, etc. If you need any extra “team” features you will have to customize builds tools such as Ant/Gradle/Maven to accommodate your wishes. Who has the time? Well I know some teams do but the fast majority of development teams do not have the time to sit down and write custom team build tools.

What I need is to take a TeamCity style build tool but introduce the concept of

  • Environments
  • Release calendar,
  • Issue Tracker Integration
  • Team Structure
  • Release Notes
  • Code Quality View
  • Signoff

I had heard the Go was more than just a build server, it was a release management tool. It wasn’t just Cruise Control with a fancy UI, it was a one stop shop for your team’s release needs. So time to check it out…

There are two versions available, an Enterprise Server edition (no pricing on the site) and a Community Edition.  Nice to see that the community edition comes with LDAP integration, often the carrot to get development teams to purchase enterprise versions.

I wanted to get a feel for the full version so I downloaded and installed the Enterprise Version.


Installation on a Windows 7 machine was a breeze, I downloaded both the Server and Agent exe and installation was quick and painless. The server installation picked port 8153 (no option in the installation procedure to choose port) and the Agent only needed the IP address.

Once installed a browser was opened pointing to http://localhost:8153/go/home where I was asked to add a pipeline. I know, a good boy scout reads the manual (I wasn’t even able to find the manual later on!) but I hadn’t at this stage and really could have done with some on screen information explaining what a pipeline meant in this context.

I think, in Go’s parlance,  a pipeline is a grouping of units of work. For example if you had a complex procedure that included

Each stage would be modelled as a pipeline and could allow for quite elaborate release models

For this demo I originally wanted to build netty from its repository on github. Netty uses Maven and although I am not a fan of Maven I do have it on my machine. Every maven build I attempt rarely works out of the box, I always thought that was the point of maven!? Well netty didn’t work out of the box as it needed another repository added to it’s pom.xml and I had neither the will or the time to go fork the project and add it. I switched to a much simpler project called netty-examples, again maven backed but completely buildable out of the box. This is not a post on maven so back to Go!

The relationship of Pipeline to source to build step is as follows

I wonder will the limitation to only allow one source repository be considered a limitation? You can always tail on to other pipelines by selecting their source as your source.

Materials is almost the same as saying SCM but for the last option which is Pipeline. As mentioned pipeline allows you to chain on to previous pipeline’s source. The list of SCM available out of the box are

  • Git
  • Subversion
  • Mercurial
  • Perforce

Surprised not to see CVS here, it’s still very popular! Materials added it is time to add the build job

Here we can add the build job, its time to compile the code. The Tasks types can be

  • Ant / Nant
  • Rake
  • Custom Command

No Maven, this is where I started to regret picking a maven based project, but a quick custom command with maven later and we were up and running.

Before I built the project I decided to take a closer look at the environments option of the tool. Predictable no environments were present and I was expecting the ability to define exactly

what an environment meant to my team. I was disappointed!

The environment relationship is as follows

It is pretty simplistic and lacked the sophistication I was hoping for. Yes I understand you can change anything with environmental variables but I was hoping to move away from name value pairs and into something more structured. I created an environment for each of the stages in my pretend team.

I assigned the build pipeline to the development environment and pressed the build project. Several iterations later, I had dropped netty for netty-example and I had a working build

Here is a view from build console

And finally a glowing green light to give any technical a warm and fuzzy feeling

So far we have a build that is linked to an environment and looking at the environment dashboard you can get a great overview of where your different stages are at

And once you spend the time to configure everything you can start to see where Go is different to other build servers


I would have to spend more time with Go to really be able to give it a proper evaluation, five hours is just not enough to make an informed decision on its usefulness to a global development team. I do like the concept of environments this is probably the one killer feature of the product that sets it apart from all the other build servers I have used. I feel it could have been more sophisticated in terms of environment definition but the environment variables do allow you to achieve all I would really need.

I felt its core build infrastructure was not as mature or as powerful as TeamCity. It lacked the feature set that TeamCity has to offer out of the box. TeamCity caters for almost anything you can throw at it and has great integration with most build tools and plugins.

I don’t think I will be dropping TeamCity in favour of Go any time soon but I will continue to monitor the product. You can download a copy from


5 thoughts on “Five Hours with ThoughtWorks Go

  1. Pingback: Five Hours with ThoughtWorks Go | Agile | Syngu
  2. Pingback: Pedro Newsletter 28.11.2011 « Pragmatic Programmer Issues –
  3. I would have hoped from a more conclusive statement: You think “Go” is good but you feel you need more time to check it more. Maybe you should think about writing a Part II for this post, in which you give a definitive assessment of “Go”.

    • I didnt feel 5hours with Go allowed me to make a full conclusive decision on Go. The one decision I made was not to use it, so perhaps I voted with my feet.

      I will wait for the next version before trying it out again, it offered very little over Cruise Control than a prettier GUI

  4. > will the limitation to only allow one source repository be considered a limitation?

    What do you mean by this?

    In Go, a pipeline can have any number of materials, which can be either a source repository or a previous pipeline.

    In the wizard that helps you to first set up a pipeline you are only given the option to define one source for materials… but you can add additional materials later via the Admin UI.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s