By May 28, 2010

Zero Configuration Development Environments

I have been working on getting set up this week to develop for my new, awesome employer, TrackAbout.

In doing so, I have once again felt the pain of getting a development environment configured.  I forgot how painful it can be.  This is in no way a reflection of TrackAbout, the truth is most development environments are a pain to get setup.  Unless you're actively trying to build a painless development environment, it is going to probably be the opposite.

I’ve seen a large number of development environments and I’ve built my share of them.  From all this, I have a pretty good idea of what I consider ideal, what we should strive for.


The basic outline

  1. Install non-scriptable tools or start with a fresh image.  (Basically getting IDE and SQL Server installed locally)
  2. Get branch from version control.
  3. Build database
  4. Build code
  5. Local deploy

The idea here is that I should be able to either get an image that has my base tools installed, or install them myself, then pull down one source control location and everything else that happens from there is the result of build scripts or some other automated process.

I know, it is easier said than done.  Let’s break it down step by step and look at some of the possible solutions.

Install tools

If you are in an organization where everyone will have the same hardware, it is much easier to create an image of a developer machine with, say, Visual Studio and SQL Server installed.

Another possible solution is to create a dev VM that is maintained and updated regularly, so that it has all the required tools and you have a uniform structure.  I have tried this approach, and I find that the biggest problem is that many times you want to run native to get the performance improvements.  As hardware capabilities increase though, I am seeing this as a more viable route.

Finally, if you can’t get either of those situations, it is ideal to put all the tools that must be installed on a network share or some other easily accessible place.

Ideally, you want to keep the number of required tools down to an absolute minimum.  In most .NET environments this should be Visual Studio and SQL Server.  The other kinds of tools can be handled via dlls (usually).

Get branch from version control

Ideally, you should be able to point a person to one source control location, and that should get everything necessary for them to build and deploy the entire system locally.

If different applications your organization is developing have different branches, then you might need to check out one location per project, but even that can be automated to some degree with a “get latest” script or symbolic links.

Build the database

This one is kind of hard.  It requires quite a bit of forethought on how to get this working.  The idea here is that I should be able to build the entire database from a set of scripts.

The challenge is getting together a process which allows for the construction of the database from scratch and to populate tables that are required for the application, and be able to apply patches to existing databases.  I won’t go into how to do that here.

Build the code

There is quite a bit lumped into here.  From a developer perspective I should just be able to run one build command that is the same build that will be run on the continuous integration server and everything that I need should get built for me.

From behind the scenes, this is a difficult step.

  • You have to make sure everything works from relative paths or environment variables.
  • You have to have your scripts check to see if things are installed and install them if not (registry keys, etc).
  • You have to have all the libraries in a place that the build can find on the client machine.

The key to success here is to eliminate as much as possible and locate in one place, as much as possible, all configuration differences.

Local deploy

It should be very easy to do a local deployment of the application.  For .NET developers this usually isn’t a challenge, but in the Java world it can take some thinking on how to do this properly.

At anytime someone should be able to deploy locally to their machine.  Ideally, anyone should be able to take a build from the build server and deploy it with a single command.

It is all about the mindset

Basically, you have to think about zero configuration development environment from the beginning if you really want to be successful at it.  It is much harder to add it on later.

You do have to weigh the effort involved carefully though.  Most developers only set up their configuration once or twice. If you are going to have a growing team where you are constantly adding new developers, you should probably put considerable effort into getting as close to zero configuration as possible.  On the other hand, if you have a small team and don’t have new developers very often, it might not be worth the extra effort.  You have to find the balance.

In all honesty, my experience at my new job has been pretty good in contrast to some of the development environment setups I have seen.  There is a huge amount of consistency in configuration locations, which is good.

I’m looking forward to figuring out how to make it easier for the next guy though, once I understand everything better myself.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."