jb's Blog

Archive for the ‘Software Development’ Category

Setting up a new project at Mindscape

Tagged as Software Development

One of the questions we regularly get asked is how we go about building our software. Like most development teams we use quite a bit of assistance in the form of automated scripts, supplementary tools as well as Visual Studio for getting the job done.

So to give you a better insight into how we do things, I thought I would quickly elaborate on what we would do if we were setting up a new project to highlight where we are getting some leverage from tools.

1. Start with the Right Structure

One of the things which always helps is setting up your source code and associated assets in a proper structure. The first thing when setting up a new project is to get organised. We typically find ourselves storing code, reference assemblies, documentation and tools.

So our initial structure looks like this:

This structure is pretty standard if you have worked on OSS projects or the like. Note, all the source code goes under Src Having a consistent structure means I know where to find things. Why would you not do this?

2. Put it in Source Control immediately

We primarily use Subversion and maintain a number of repositories for the various things we work on – e.g. One for Mindscape, one each for side projects, one for our work on Valuecruncher etc etc.

If you are using SourceSafe – get off it immediately and look at Visual Studio Team System, Subversion or SourceGear’s Vault as alternatives. Ultimately you want a solution that integrates well with how you are performing your development and provides enough capabilities for you to not get caught up spending time worry about it. For us, this meant something that could work across the Internet (so we can work at home some of the time!), be decoupled from Visual Studio (because we love the file system) and was easy to get installed and running with. We use TortoiseSVN in conjunction with Subversion for tooling – this works really well for us.

One of the very useful views over our Subversion repository is the timeline view of activity.

We use Trac for this which Andrew introduced to us very early on in the Mindscape life, but really its just an enumeration over the change sets so can be achieved regardless of how you manage your source – TeamCity also allows you to get the same view. This is amazing for watching what is going on – how frequently are people committing, what are they committing and also you can continuously code review by watching the changes.

3. Make it Portable

I tend to work across a number of different machines (work, home, roaming, VM’s) and often want to work on a project from all of these environments. Also we have a build server who wants to help as well by building and testing things for us So it is critical that the whole solution and everything required to build it should belong within the confines of our source controlled structure.

In our structure above, the Lib and Tools directories have a big role to play here. Any references assemblies are referenced out of Lib – our only real exception to this is references from the .NET Framework. Any tools we need to use to either build, deploy or test the solution are stored under the Tools folder. This means our build server in particular can grab a clean copy of this each time it needs to do a build and can actually build it without us having to spend hours setting up dependencies on the box.

One of the other important things is to make sure that an environment can be provisioned largely from scratch. If you are familiar with Unix conventions, you will know about Makefiles and the role they play. I look to set up something similar but generally with batch files or Powershell scripts to provision the environment.

4. Automate the build as soon as possible

We use TeamCity to manage our automated builds, both integration and nightlies – it is a fantastic product and well worth looking into if you don’t have something already. We used Cruise Control at Mindscape prior to picking up on TeamCity, and my personal take is that TeamCity is massively superior in all aspects, but mostly for just removing the administration hassle in setting things up.

At a glance you can see everything is good in the world of LightSpeed

TeamCity acts by monitoring our Subversion repositories and based on the appropriate trigger (e.g. code check in) will grab the latest copy of the source and kick off a build. We script the builds themselves by using MSBuild which generally will do these things:

• Build each code solution involved in the system
• Build any test structures required (e.g. databases – those early build scripts come in handy at this point!)
• Run all unit tests with code coverage
• Run any supplementary static analysis checks (e.g. StyleCop)
• Run any supplementary actions (e.g. Build an installer)

One of the advantages of having using an MSBuild script is you can always crack open a command line locally and run this yourself. It should succeed, or you should be breaking the build (no, that’s not a good thing!).

Often we have our build process automatically deploy to a test environment (e.g. update a website). Again this just saves you time and increases your confidence in making changes since you can immediately get feedback.

And we are done..

Nothing I have described above is particularly hard, especially once you have incurred the one time setup costs of getting Subversion and TeamCity installed somewhere. The benefits are huge though – working software from the get go, quick feedback when I make changes (and break the build..) and no wasting my time having to “prepare a release” or the like.

One of the most valuable investments you can make in a project is to get the process and tooling right up front – this leaves you free to focus on what matters – writing good code.

Add your comments
Posted by Jeremy Boyd on 5 March 2009