Personal Continuous Integration

I've been experimenting for some months with distributed version control system (Mercurial and Git) on various personal projects.

The most interesting of the personal projects was a branch from an active code base that I wanted to extend in a slightly different direction. Because my changes are going in a slightly different direction, they were not likely to be included in the original code base for a very long time. That meant I was going to be "on a branch" from that original code base for a very long time.

Past experiences with CVS and Perforce suggested that being on a branch for a very long time could be a problem. Perforce was not as bad as CVS, but still it was difficult to maintain a separate personal branch and "keep it healthy". Inevitably I would make changes that were harmful to the main code, and not realize I had harmed it because I was not getting all the feedback that is available to developers on the main code.

The main code developers have a continuous integration setup which runs automated tests in many different configurations and summarizes the results to a central location. The results are easy to browse and easy to watch as they evolve.

Since I'm not on the main code, I don't have that nice infrastructure to support my private branch. With distributed version control, I have all the power of a version control system (incremental checkin, revert to previous point in time, branching, merging, etc.). Why can't I have all the power of a continuous integration server for myself as well.

Why Not Use My Own Machine?

I'm sure others have already realized this, but with the ease of installing, configuring, and using the Hudson continuous integration server, I can run my own continuous integration server which compiles and tests code from my personal version control, before it is ever pushed to any other person (or system) in the organization.

Setup Idea

1. Install Sun JDK (needed by Hudson)
   
2. Install Hudson continuous integration server
   
3. Run the Hudson continuous integration server
   
4. Install distributed version control (Mercurial or Git or ...)
   
5. Install Hudson plugin for selected distributed version control
   
6. Clone the development repository from the company central location
   
7. Create a new Hudson job which monitors the local repository, checks out the source from the local repository when something changes, compiles it, tests it, and reports its results
   
8. Start making local changes, checking them in, and enjoying the benefits of continuous integration test runs while developing the code, without the danger of checking into a central repository before the code is "done done"
   

I think those setup steps could be reduced to less than a day, and that day would repay itself within the first 4 weeks of work as developers were more confident in their changes before they shared them with others. I don't yet know if the idea will work for "real" developers, since I'm the manager trying to provide them the tools and environment to be successful, rather than a full time developer. We'll see if the idea actually reduces the feedback loop, and if it actually is viewed positively by the developers. What Will They Value? I think developers will gain

1. Rapid feedback on their changes
   
2. Background work (compiling and testing while they work on other steps)
   
3. Isolation of their changes from others until they are "done done"
   
4. Visibility to the impact of changes from others in their test environment (integrating changes from others onto their branch is a "trigger" event, just as checking in their own changes is a trigger event)