Trade-offs of local vs remote development workflows for a web development team

Question

We currently have SVN setup on a remote development server. Developers SSH into the server and develops on their sandbox environment on the server. Each one has a virtual host pointed to their sandbox so they can preview their changes via the web browser by connecting to developer-sandbox1.domain.com. This has worked well so far because the team is small and everyone uses computers with varying specs and OSs.

I've heard some web shops are using a workflow that has the developers work off of a VM on their local machine and then finally push changes to the remote server that hosts SVN. The downside to this is that everyone will need to make sure their machine is powerful enough to run both the VM and all their development tools. This would also mean creating images that mirror the server environment (we use CentOS) and have them install it into their VMs. And this would mean creating new images every time there is an update to the server environment.

What are some other trade-offs? Ultimately, why did you choose one workflow over the other?

Answer 1

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.

Answer 2

Local development > Local VM development > Remote VM development

Start with the first. If it doesn't satisfy, you might move right, but consider very carefully why are you doing it:

• Huh, I cannot get version a.b.c of XXX for local dev boxes. Huh... is it an ancient version? Why don't you upgrade? Are you sure it still receives security updates?
• Ermm.. production OS is different from what my devs can use. Are you sure that you cannot make your code more portable and it might be worthwhile? What if at some point you need to change your production OS (not likely, but it sometimes happens)?

... meaning: it's bad to tie yourself into very specific environments.

Local development is often faster, simpler, more convenient. Esp. using tools locally is normally much better (I think I'd be significantly hindered if I had to run Eclipse remotely, or give it up). But running your code in your own box often means faster turnaround, easier interactive graphical debugging and a lot other niceties.

Sometimes a VM is required, but unless you have no other option, it's good to avoid it.

There might also be performance reasons, but really, beefy machines for developers are great inversions- hardware is cheaper than people. Of course, you might be developing for a massively parallel cluster and you really cannot put one of these in each desk, but that's fairly uncommon.

All of this, of course, doesn't negate the need to have testing/QA environments which mimick as closely as possible production. But then, I'd say, even VMs might not cut it.