Setting up multiple development environments'm

Question

I'm a solo developer working on a typical web project (Django + PostgresSQL) using Eclipse as my IDE and Subversion for source control. So far I've been working on a single development machine that I have setup myself. Recently, I've been asked to do some work at the customer site and there have also been a few occasions when it would have been useful to have access to the site at home. I'm thinking about what the best way to set this up is. Unfortunately, for various reasons a laptop is not a viable solution, so the solutions I am thinking of are:

1. Installing all the necessary development tools on each machine (PostgresSQL, Eclipse, Django, Python + librariries etc.) and keeping the code in sync using SVN.
2. Setting some kind of VNC access on my development machine and accessing it remotely to do work.
3. Creating a Virtual machine and copying the image between all the machines using a pen drive.

The advantage of #1 is fast local development, but then I have to setup all the tools on each machine and deal with their configurations and keeping everything in sync. Also, to share code between the machines, I'd have to check it into SVN even if it's not "ready." Solution #2 solves this problem, but at the expense of slower UI experience. Finally, #3 seems like a nice solution, but I'm not sure if I can really fit a virtual image on a pen drive and I'm not sure about the performance.

I guess there's not really a "correct" answer, but I'm throwing this out to get ideas and suggestions from people who have been doing this longer than me. :)

Answer 1

I'd say option number 1 is still the best. I'd assume you only have one computer at home and you can work off of that one, so the setup should hopefully just be a one time thing.

You're right though, the setup time is quite tedious, however it does in fact make up for the slow UI of using something like VNC to work remotely. Your problem with committing code that may not work is a valid one, however if you're concerned about that, simply comment out the broken code and ensure that your latest version compiles.

Working through a repository is the most efficient method, especially if you're working on a fairly large project. It's too bad you don't have a laptop, setting up all the tools on a laptop makes coding/working from anywhere (provided you have an internet connection) especially convenient.

Anyways, option 1 is my preference, I hope it helps.

Answer 2

If the machines have e-sata ports this might be what you’re looking for. Why not do a combination of one and three, create a base vm deploy it to all your machines at once and keep the code in sync using svn or some other synchronization tool? If you don't want to constantly check in and out of source control something like drop box would allow you to keep working directories in sync as long as you don't mind having a third party be able to view your code although they probably won't bother. Another option would to create a "working" branch that you always check in and out of, and only move code to the trunk when it's stable enough and somewhat finished.

Answer 3

Running a VM from a pen-drive (even a fast one, which most aren't!) will suck big time.

You could copy it locally or use a USB HDD though, or even a solution like Live Mesh to sync it.

Answer 4

Use version control. If you are worried about checking in "incomplete" code, use branches (branch for development) or tags (tag "completed" code). Committing "in progress" work has its advantages (good undo, helps you write good changelogs, etc.). Also, documenting your "setup" process so it's easier to reproduce is good too.

Answer 5

Also, to share code between the machines, I'd have to check it into SVN even if it's not "ready."

Git very much solves this problem explicitly. As far as offline development goes you should give Git a try. It makes managing offline repositories really simple. And because of its distributed architecture offers a handful of conveniences when moving between environments. It was designed to make the workflow checkin early checkin often. I think you will find it offers things that SVN doesn't.

For example you can keep different repositories around for different environments and easily merge changes between them. That way you can have repositories bundled with your VM images. And they can diverge dramatically but still be easily to merge back together.

The merging is what makes Git such a dream to use.

Watch these two presentations for a nice overview.

Linus Torvalds on Git (more on the design philosophy of Git)

http://www.youtube.com/watch?v=4XpnKHJAok8

Randall Schwartz presentation (more practical overview)

http://www.youtube.com/watch?v=8dhZ9BXQgc4