Version Control – Advantages of Using a DVCS for a Solo Developer

First, having multiple builds per project in TeamCity is really the way to go. The nature of the platform makes it really easy -- the copy button is there for a reason.

In any case, when we were on SVN, we typically ran 2 builds for each project -- one pointed at the main development line (in our case the trunk) and one pointed at our release branch. We carried this build setup over to HG while following a branching model similar to this one . Only real challenge has been finding a new funk schwea about build numbers now that we could no longer use current SVN revision number.

We try and encourage folks to push relatively often, especially when there is lots of work going on at once and we wanted faster feedback cycles. Just because it is a DCVS doesn't mean you have to only push once a day or something.

aI have been working for the past 4 years in variations of the environment you described. Here is my experience with them:

Local environment (http server installed locally + other systems)

Although it is arguably possible to deploy the environment in all OS, the reality is that you will face with a lot of problems regaring different configurations, available modules, library versions... It means that lots of developers will work on his very own environment, different among them and different from production environment.

This setup is very nice with the developer: it is very fast, he obtains knowledge about the whole picture, very useful for trying new configurations or alternative software. If the developer has some sysadmin skills, he can fix configuration options, change the enviroment so some specific feature is easy to develop or test...

As the code and development tools are also local, daily work is very fast.

Local VM (dev environment in a VM, running locally)

You will need to create a dev virtual machine and send it to your developers. Also, you need to provide updates (probably as another VM), but some developers will not install it if they have customized their personal VMs too much. You also need some kind of global configuration, while still allowing particular settings for each developer. But then you will face the problem of developers tunning their VMs so much that it becames to different from production.

The developer needs a very powerfull machine, specially for web development. Nowadays I'm using a dev VM, a windows VM (to test things in IE browsers, for example) and the dev environment. My dual core and 8Gb of RAM can't handle that nicely, is a real mental pain to work with that setup.

There are three alternatives about code:

• Code is local, deployed to the VM to run it: Working with local development tools is very fast. Although most tools have automated deploy options, in my experience they didn't work very well when you need to work in the other way (update local code with VM code). . Works better using a SSH connection for particular tasks (i.e. global searchs)

• Code is in the VM, shared with local development tools using some remote-acces solution (samba, sftp...): Depending on the developer SO or personal setup, it might not work very well. Potentially you will face problems about permissions, polluted directories (aka Thumbs.db and .DS_Store everywhere) and random disconnections. Some tools features (like indexing or global searchs) will be very slow. Works better using a SSH connection for particular tasks (i.e. global searchs)

• Code is in the VM, the developer works using server tools through a remote shell. Good solution if your developers like this setup and you can find a good replacement for each local softare used by your team (very unlikely, specially for designers)

Remote Environment (dev environment is in another machine)

This setup is the easiest to to maintain, as new configuration options or software just need to be deployed in one place. With a good server you can host up to 50 developers, so the worst case for mid-sized companies will be to maintain 3 or 4 development servers.

You will face privileges and security problems: some of the developers might need root access to do their job, so they will be able to change the environment, potentially breaking it and stopping the whole team (or worse, losing the in-progress code). As the number of developer grows this will become a serious risk. In my experience, in a machine shared by 20 developers expect a broken environment at least once per month.

Obviously, it has network dependency: if the developer does not have network access, he can't work. You will need a VPN setup to provide access to out-of-office developers, access to remote clients or testers, access to dev environment from your sales people outside the office... Security becomes more important than ever.

For code, very much like Local VM setup, plus adding networking issues. Expect frustrating slowdowns and random disconnections.

Remote VM (dev environment is in a VM, running in a remote machine)

Pretty much like Remote Environment setup, but you can scale it better. On the other hand, you get the problems of deploying the dev environment to too much different machines, so chances of differences among them and production environment are higher.

My personal choice

Use LocalVM and local code. Speed in every day task is very important if you don't want to make your team angry, so local code is important. Most tools works fine for remote deploying, and any "advanced" developer using the reverse way (vm->local) probably can figure out how to do that nicely by himself.

Invest money in powerful machines for the team so the machine speed is not a stopper for anyone. A remote cluster of VMs or a auxiliary and cheap laptop can be very helpful for developers working with heavy development tools.