Maintaining Dev Environments Across Multiple Machines

Over the last few years I’ve ended up with 4 different machines that I use on a regular basis. I have workstations at the office and at home, a large laptop as a portable workhorse, and a small laptop for travel. Each of these has a development environment on it so I can get work done, but the time cost (tax) of switching between machines has been wearing on me. Of late I’m finding myself with smaller and smaller windows of time. When I have 30 minutes to get something done, I want to get a full productive 30 minutes – not to spend 15 of those minutes getting my environment up to the latest for the project I need to dive into.

I came up with a fairly involved solution to solve this problem. Here are the aspects I wanted to address:

  1. Local staging and development site configs (hosts file and virtual hosts config)
  2. Code that isn’t ready to commit
  3. Database content
  4. Software updates and configuration (Apache, PHP, MySQL) issues

The first step, which I actually completed a while back, was to move my /etc/hosts file and my /etc/apache2/extra/httpd-vhosts.conf files into Dropbox, then symlink them back into place. This sounds a bit scary, but it’s actually worked like a charm – no issues to date. :knock wood: This allows me to keep my local development urls in sync across all of my machines.

Since the Apache virtual host definitions (including file paths) are being sync’ed across machines, they need to remain consistent. Also, I wanted to be in a position where I my uncommitted code changes could be synced across machines. Dropbox is the tool of choice here again. My setting up all of my web environments inside my Dropbox folder, they will automatically stay in sync – including SVN/Git commit status, etc.

Database content was a big catalyst for designing this system. More and more of my development projects are reliant on some data and/or data conditions. Getting data entered and updated on every machine can be a real time sink. I decided to use ~25 remote databases on one of my servers for this purpose. Then each machine connects over the internet and reads/writes content to a common database server.

But what about when I go on a plane? How can I take advantage of the uninterrupted development time on a plane if I don’t have internet access and can’t connect to my remote database? Here’s what I came up with for that.

  1. Create a new Dropbox account, one that will only be used for this purpose.
  2. Install the linux Dropbox client on the database server, and run an hourly CRON to export each of the databases and store the latest dumps in the Dropbox folder
  3. Share this Dropbox folder with my main Dropbox account so that they database dumps are made available on each of my machines.

The last piece of the puzzle is moving over to MAMP from the built-in Apache and PHP binaries, and my self-installed MySQL set-up. I know a lot of people who swear by Homebrew or MacPorts, but I’ve also seen these break on various OS updates. Fixing these installation issues on a single machine is one thing. Having to fix them across four different machines is something else.

When I upgraded one of my laptops to Snow Leopard, my MySQL installation (I had installed, as usual, from the packaged download on broke in a strange way. I spent a hours trying to get this fixed over about a month period and never did. As a result, one of my workstations is still running Leopard because I couldn’t afford the potential downtime if something broke there.

With MAMP, everything is self-contained outside of the standard packages and environment. It has its own set of limitations, but it’s really unlikely to break.

There are some issues with this set-up that I’m well aware of.

  • Dropbox sync cannot be prompted. There’s no way to say “Hey Dropbox, I need you to sync this folder right now!”
  • I know that conflicts can and will happen with Dropbox. I tried putting my Address Book data in Dropbox a while back when I was looking for a solution to sync my contacts across multiple machines.
  • I would still need to import the database to my local MySQL server and adjust the app config to point at it instead of the remote database server, but the set-up time should be greatly reduced. What I don’t have is an easy solution to push data changes from the local environment back to the remote database server. Setting up a multi-master MySQL cluster might be another workable approach, but I have no idea if that’s feasible with machines that are only on a small percentage of the time.
  • I would still need to manage software updates, configuration changes, preferences, etc. across each machine.

I started to implement this configuration a week or so ago and then stopped.

I realized that not only would I have to get this set up once, but I’d also have to mirror that set-up and configuration across all of the other machines as well. This may be a solution as it does solve a number of problems (and would probably be pretty manageable with just 2 machines), but it isn’t the right solution for me, right now.

I’ve come up with a different solution; a simpler solution: I’m going back to a single laptop.