My name is Marius Ciotlos and I"m a Delivery Manager at Betfair. Since I started working in the IT industry I"ve been in a lot of different roles from software development to network support and computer technical support and after so many years in the industry, I hardly get excited or impressed by a single tool, because so few are actually innovating.
Many tools out there are very similar with just different flavors, or so specific in their task that it is up to you to find how to build your workflow with them.
The tool I found is called "GO" and it is being developed by ThoughtWorks. The tool is difficult to find because of the name (simple, elegant, however not even close to being unique). There is also the disadvantage that there is the "GO" programming language sharing the name!
But enough with the introductions, let"s get down to the details behind this tool. GO was developed to be a tool with which you could do "Continuous Delivery". I would like to avoid touching that subject because there are so many papers out there about this topic and every technical writer puts their own twist on the terminology. If you disconnect yourself from thinking about it like that, the tool becomes much more. It"s a very customizable workflow tool. And above all, it"s now open source.
I have been introduced to GO, just a month ago in a workshop at my company. Some could think that we"ve been spoon fed biased information by some contractor that is paid or working with ThoughtWorks. However that is far from the truth. GO was at that time just a name of an obscure tool (for me), that maybe we should have a look at. I have been skeptical with "off the shelf" complex tools as I"ve had my fair share of disappointments with some, that always advertise themselves as doing a lot that end up half of the time getting in your way.
GO is a Server -> Agent type of architecture, where you have your main server with the UI, and many agents that connect to this Server and receive commands. Agents can run on windows, Linux and Mac OSX, and it"s up to you how many you want (you can even run more agents on one machine).
On the server you have:
Your agents will have tags to specify what they can do (for example run bash, run python, run GIT, run SSH) and your Jobs have tags too, to specify what resources you need for that Job to run. The server just matches the right agent for the right job!
We use it for server deployments, running tests and running infrastructure automation. However, because of the way it"s built, you could use it for a lot of other purposes. The way it works:
The main features that allow you to achieve this high level of flexibility:
Custom commands are a list of commands that you can use to do stuff in a task. The nice thing in GO is that you can run literally anything using a terminal (Linux, Windows, Mac OSX). If the basic commands are not enough for you, it"s always possible to create more complex commands by yourself, using scripts (think of PowerShell, Python, etc.). Custom commands allow you to also track the status of the command that just ran. We have used Python scripts to have even more flexibility to process output and send back the right "status code" so you know when a task (which is running the command) has failed or not.
Artifacts are the second great concept in GO, where a job (which has multiple tasks with custom commands) can generate some output and you could "tell" GO that it is an artifact. Even if you only have two types of artifacts allowed by GO, the Build Artifact is generic enough to be anything. With artifacts you can bring in the tool more information from the output, but you can also provide these to a different Stage or Pipeline for usage. Imagine a script that generates a temporary binary that you need further on down the pipeline. You could use artifacts so you no longer need an external repo for something that is so volatile. Also, the Test Artifacts are the way GO can interpret test results for a Stage.
Based on artifacts you can have some custom tabs that load HTML you generated with a command, to view directly in the tool.
The entire configuration for the server sits in one versioned XML file, and if the UI is not enough, you can always manually edit. This feature is only available to the Super Admin as it is very easily possible to screw things up from there. The Configuration XML sits in a text area that has a lot of validation, but one thing you will probably end up doing as you build your workflow is rename some Pipelines, and this can cause you problems.
You can find more resources about the tool here:
Public forum https://groups.google.com/forum/#!forum/go-cd
Documentation: https://go.app.betfair/go/help/index.html
Older community page: http://support.thoughtworks.com/categories/20002778-Go-Community-Support
Introduction webinar: http://www.go.cd/2014/03/10/go-webinar-recording.html