The independent trunk

The independent trunk

Manging source control is a fundamental task in any software development environment. I do not claim to be anything of an expert in the area, but I have a theory for setting up the environment that Id like to share with others.

Lacking a name for it I’m going to call it The independent trunk. The idea is to have all the requirements for building the system checked in under source-control in the trunk. This includes binaries and third party components, build scripts and build tasks. While it might not sound as much of a revolutionary idea, I believe it is one take a closer look on.

**All you need to build the system, and all you need to set it up. ** A few years ago we had a release process that took hours, if not days. We had to find all the documents specifying how to install, configure and update the system we were working on at the time. We had to place all the documents in a specific release structure, together with the different parts of the system. Clients, web-pages, database scripts, all these had to manually be placed in a structure and verified for a release.

Needless to say, a release process like this costs money and if you want to release every other week it costs too much. So when starting of our current project we said that the release process had to be automated. Inspired by Mary Poppendick’s book “Implementing Lean Software Development” I created a build that we called the package build. The idea is that it takes all the parts of the system and combines them in a releasable package. This means among other things that we started to check our configuration documents into the source-control system, so that they are available for the build system to be included in the build structure.

The package build has of course evolved since then, which is another story all together, but its fundamental purpose remains the same. Important to note, however; is that all our builds can be run on a developer machine. This includes the package build. ** Your system is not only your source code.**

The system were building is not only the source-code and documents, its much more than that. It is also a product of our development and the tools and third party components that we combine our code with. This means that our system is tightly coupled with the versions of the tools and the components we build it with.

We started by adding third party components in a folder under the trunk called References. By placing third-party components in the source-control they don’t have to be installed on each individual developer machine, and you guarantee that each developer will use the same version of the third party component. Doing this was not straight forward to us as a team and as usual we had allot of discussions around the subject. However it turned out to be a good idea. Naturally this means that there might be some big files checked into source-control, but the benefits of having them checked in far outweighs the drawback of paying a few bits of extra storage.

Our development environment is based on Microsoft Team Foundation Server 2008. One of the new features in TFS2008 is that the build definitions can be placed in any part of the source-control, opposed to placed in the special BuildTargets directory in TFS2005. While converting to TFS2008 we placed the build definitions a part of the solution its supposed to build.

These two changes in how we use our source-control system means that; no matter what version of the system a developer wants to build, he or she can fetch it from the source-control. This results in a structure that is a ready to build using the versions of the third-party components and build scripts and setup instructions used for that specific version of the system.

This is extra use-full for someone who just received new hardware as all the have to do is make sure Visual Studio is installed, get latest and run a local Package build. Then they are up and running with the latest version of the source-code compiled and ready.