Crazy Chess: pre-development setup

In the beginning stages of development our “customer” doesn’t really know what they want more than at the most vague level. They want a program that plays chess. They have agreed that this can be a command line program (this wouldn’t ever happen but it simplifies my task). We’ve agreed to a billing system based on work performed, not an all encompassing rate to finish the project…or we’ve been hired on a salary to implement this thing for our boss. We’ve agreed to an agile process based not only on the vague requirements but also because it is comfortable for us. So we’ll work a bit on tasks the customer says they want for a short time, show the customer the result, and get input about changes and future direction. Releases happen when the customer decides the project has implemented enough features to release to customers.

So in other words we have a go.

The first step is to set up a development environment. The customer has dictated we use Open Source frameworks and services. They’ve also stated that the product will be released under an Open Source license. This makes writing about it easy 😉 We’re also expected to limit expenses, requiring we use free services. After some minor debate we’ve decided to use github to host the project.

Every agile project should have Continuous Integration. There is indeed a free CI service that ties directly in with github: Travis CI.

We’ll use C++ because well, that’s what we do. We also know that chess engines need to be pretty close to the machine in order to perform well so C++ is a good choice for this need.

We’ll use Boost and CMake because we have experience with them and know they work relatively well. If something about that changes we’ll revisit this choice.

Setting up github is fairly straight forward so I won’t go into much detail. Create an account, add a new project, follow the directions. Hardest part in the whole thing is probably setting up git on your computer, which is probably not hard at all (`apt-get install git` on Ubuntu).

Setting up Travis to build your project is also incredibly easy. Just register/sign-in with your github account. If your repository already exists it will appear in your profile. Click the wrench icon to configure it and turn on, “Build only if .travis.yml is present.” Then go back to your profile page and turn on the repository. You’re now continuously integrating the project.

Making a C++ project build though is a bit more work (why we turned on the yml requirement). C++ doesn’t have really good dependency support. In fact it has none at all. So this means we have to do everything by hand. The Travis help tells us how but it still requires some messing about. Namely Travis uses a Ubuntu that is older than what you’d currently download; its latest boost version is 1.48–see the history of the .travis.yml file to see some of what I went through to figure this out. We believe we can live with this.

The final result of the travis configuration thus far looks like this:

notifications:
  email: false

language: cpp

compiler:
- clang

install:
  sudo apt-get install --force-yes --yes libboost1.48-all-dev

script:
  mkdir debug &&
  cd debug &&
  cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=clang++ .. &&
  make check

This sets up our CI server to install our only dependency, boost, and build the project from scratch. Travis doesn’t do incremental builds so this happens every time.

Normally we might chose something more powerful and customizable like Jenkins. In this case though the requirement to use free, online services sort of forces our hands. Travis will do the build and run the unit tests. It will then give us a green or red light based on whether this succeeded or not. Later it’ll push releases into github for us. These are the bare minimum required of a CI server. It would be nice to have complete reports, graphs, and such for unit tests, static analysis, code coverage, leak detection, etc… As we learn more we may add some of these steps, but it’ll be a pass/fail type thing without graphs.

The first section in this configuration turns off the email notifications. In a corporate environment you’d probably have these. As my github is connected to my personal account I don’t want this, and besides there are better ways. Instead of email notification I installed the tray application that shows the status of my CI projects on my desktop.

I also added the status icon to the main github project page via the README.md content. Doing so was not all that hard:

 [![Build Status](https://travis-ci.org/crazy-eddie/crazychess.svg?branch=master)](https://travis-ci.org/crazy-eddie/crazychess)

This creates a Markdown link on top of an image. I got the information from directions supplied in the Travis help on status images. Unfortunately it was not entirely correct so I had to additionally look up how to make a Markdown link out of an image.

With this and some cmake file setup we have the beginning of a project. It has a revision repository and it builds and runs unit tests on every check-in. In the future we will add additional levels of testing as well as release pushing (continuous delivery) but for now we have a solid starting setup.

With this done we have a minimally building project (it builds a single unit test that tests nothing) and a little status light:

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s