CI with GO - Part 1

Continuous Integration at some level is almost a given in most software teams at present. There are many ways to put CI into practice. This series of posts is aimed at discussing implementing CI from the perspective of a .NET developer using ThoughtWorks GO as a CI platform.

In part we cover the very basics of getting a basic build up and running.

I thought it might be worthwhile for me to stipulate what my version of doing Continuous Integration is...

"Every time a change is made,

 we want to know that everything works..."

So what defines "working"?

As a guy in a team building .net systems, the first thing is:

"The solution should always build"

Not such a lofty goal, I know. Yet still, I've seen it happen before, some guy forgets to check in a file, goes on leave... basically not a good way to make your team like you.

So the very first logical thing to do is make sure that the stuff in source control gets checked out on a regular basis, onto a neutral dev box, and compiled. And if for some reason it doesn't you know about it as soon as possible and sort it out.

Sounds super simple. And it is.

Basically all I need is something to do source control checkout (or update), and run msbuild against my solution file.

Using Go for Build Automation

Obviously you will need a machine to be the build server. And you will have to put stuff on it, that lets it build stuff. Go forth to the download go page and download the server, and the agent.

The server is basically the thing that defines "what" happens - The agent is the thing that does the previously mentioned "what". You can have multiple agents, on multiple machines.

Since you are building VS solutions, save yourself the excruciating pain of trying to get msbuild set up correctly from scratch and just install whichever version of VS you are developing with on the machine running the agent (oh the horror... trust me, just do it).

In addition to installing the tools required to build your solution, I would recommend adding the paths to your tools to the %PATH% environment variable.

You can do this at a later stage, just remember to restart the Go server and any agents so that they will read the updated environment variable.

For now, update the path environment variable to include the path to your source control client of choice (git/svn whatever) and to msbuild - e.g. (C:\Windows\Microsoft.NET\Framework64\v4.0.30319).

Installing the agent and server is super easy - double click, follow the instructions. They are java things (the server runs its own web server), and will appear as services.

So, recap - pick a machine, install the server and agent, install vs - job's done. If you did it right you should see something at http://<localhost or machine name here>:8153/ (usually "create a pipeline" appears first)

So now that we have all this fancy automation stuff, how do I build my solution already?

The first thing you need to do is create something that represents the process of

• watching source control for changes
• getting stuff that's changed
• running msbuild

That "thing" is called a pipeline in Go. Why do I need something called a "pipeline" if all I'm doing is building a solution? For now just look past the naming and imagine it's called a process or a workflow or something...

Step 1 - Create a Pipeline

So, create a new pipeline called something like ci_BuildAwesomeSolution (or whatever its called).

Pipeline group names are handy for when you have lots of pipelines and you want to logically group them (who would have guessed). I usually like having one called CI, or Builds or something like that.

Step 2 - Define Materials

The next thing that you get asked is to specify something called "materials". I prefer to think of this in terms of "raw materials" like an ore or the parts of a car, not the stuff they use for clothes.

For now, in our world this is our source code, which lives in a source control repository (although later we will start seeing that more things can be materials). Pick your scm of choice and specify where the source lives, and Go will kindly check for changes there, and automatically kick of the pipeline/process for you.

Remember which location in your repository your material is pointing to, as you may need to include the relative path to specific files when defining tasks.

Step 3 - Create a Stage/Job

This is the step where we can actually start to automate tasks that perform useful actions such as executing msbuild. You may expect to just be able to create a task straight away, but the hierarchy of Stage->Job->Task allows you to do some more advanced things other than just running a sequential series of commands. We will look more at this at a later stage.

For now you we are mainly interested in a task, which will execute msbuild against our.sln file.

The Job is the thing that contains tasks, and the Stage is the thing that contains jobs. The main stuff to take into account here is

A Stage is sequential (so a pipeline can have many of these)

Jobs can run in parallel and produce artifacts (basically these are the outputs of your process/pipeline) - so for us this is the build output (stuff in our bin folders) that result from building the solution.

A Job produces artifacts by executing tasks.

So lets create a stage called "build_stage" (or "build" if you prefer)...

with a job called "build_awesomesolution_artifacts"...

and select "more" task from tasks (the default stuff isn't very .nety)

now type msbuild (hit tab) on the lookup commands box, and it will magically auto populate some stuff for you in the command and argument text boxes.

Go just used its command repository to do the lookup and auto populate from a template. The good news is that these things are basically xml files and that you can easily add your own.

The bad news is that the msbuild snippet is wrong, but we will fix that later, and create our own custom commands

change the arguments to be:

awesomesolutionhere.sln
/t:REBUILD
/p:Configuration=Release

If your solution file was not at the root of the material directory you could either include it with the solution file parameter, or enter it in the working directory

Modify the name of the solution and click finish. Your pipeline should end up looking something like this

Step 4 - See how it runs...

Now go to pipelines, you should see your pipeline there, click the "unpause" button, and the click the play button.

If you're like me you will wonder what happened and where.

So go to the machine running the agent, and go check in...

C:\Program Files (x86)\Go Agent\pipelines

You should find a directory containing your materials. That's where the materials are checked out, and then get built by the agent process.

Assuming everything worked you now have a green pipeline.

I always tell people that I'm a very selfish developer.

I don't really think that's true, I've always tried to share as much as I know with those I work with. I believe it creates a better culture to work in, and I want feel like I'm working towards something that's generally good, and with people that care about what they are doing. 

I also usually tell people that I don't blog because I probably don't have anything original or interesting to tell people about development that they can't already find elsewhere.

This may or may not be true, but I guess it's not a good reason not to pay it forward.

The goal of this blog is to be a resource for developers (primarily in the Microsoft/.net space) to find interesting and hopefully useful bits of information and to try and promote things that I believe are good. It's my small way of trying to make the world a little bit better...

So, to set myself some goals, and as my first set of useful info, I intend to do a small series of posts that deal with CI, Automated testing and deployment, using an interesting CI server called Go, created by ThoughtWorks.