Daily builds with SVN for a small team

Question

I have a general question regarding best practices. I have a small team working on a medium-scale software project, which involves integrating code from different environments, etc. The project is a standalone piece of desktop software.

Based on lessons learned from a similar prior project that went badly, I am trying to implement some better software engineering practices.

I'd like to start by automating daily builds. We use SVN for source control, and all the developers are working in the trunk, including me. My question is rather simple:

Where locally do we do the daily builds? Should I make another folder on my local machine that is the "daily build" folder? Should I set up a virtual machine? Should I suck it up and do it in my development folder?

I understand the revision control paradigms pretty well. I'm mostly looking for how folks implement it in practice.

Answer 1

A build machine is the way to go, even for small projects/teams.

1. Get any random spare machine (ie. an old dev box).
2. Install some continuous integration software on it like jenkins or teamcity.
3. Done

It's been a while since I had to set one up or maintain a build machine, but unless it's gotten worse since a year or 2 ago, you can have continuous builds on each checkin, and a nightly build that gets dumped to a network share setup in maybe an hour with either of these products.

Answer 2

Presuming your app can be built from the command line given a clean checkout and pre-requisites preinstalled you can mechanically do it with something as simple as a cron job or scheduled task. But what you really want here is known as a continuous integration server.

These servers handle a couple of things:

• they make it easy to orchestrate the "go build this every day at midnight" or "go build this every time someone checks in" by providing scheduling facilities.
• they extend that basic build by providing feedback mechanisms -- such as emailing the whole team when Bob breaks the build.
• they can provide long-term reporting on build performance and success over time.
• can provide the plumbing to automate packaging and publishing of an application where appropriate.

Or, they are effectively the brains of a modern development and deployment process.

There are two products that are good to start with in this field -- Jenkins which is free and open source and TeamCity which is free for your scale but not open source. Both will get you where you need to go, which one to pick is really a tactical decision based on what you are building stuff in and how much effort you might want to put into configuring the thing -- not that a basic setup with either product is horribly involved if you've ever stood up a and configured a web application. They are anatomically similar so the rest of this answer will apply to both.

These products both have a central server which is what you interact with as well as a concept of build agents or workers where the builds take place. This seems a bit odd until you realize that you could be building a cross-platform product that needs a native windows, osx and linux build.

In terms of where to install it that is really a tactical decision -- they both are very flexible java products that will run on just about anything. It really boils down to avaliability of hardware / software / licensing and security -- some folks really want to keep everything on the LAN. As for the build agent that is also a tactical decision. There is no reason the agent can't be on the same box as your CI server but you could certainly drop it somewhere different if need be. Having it on the same LAN helps unless you want to do some network configuration as they do need to communicate and typically that requires some firewall hole punching.

I probably would not install this on a machine someone was actively using just to guard against someone turning the machine off. Or hosing the machine and breaking your CI process. But mechanically an old desktop will do -- we just retired a ~2005 era HP desktop that was the main build server for every one of our dozen plus QA sites that got built pretty frequently. It's main issue was that we could only put 2gb of RAM in the box so we could not cache a lot of things in ram and it would page out to a slow disk made by the lowest vendor operating well beyond it's expected service life.

tldr: get Jenkins or TeamCity, install on a spare desktop, conquor the world.