So you want to build a software team? Part 1: Sandboxes

The plan is to make this into the first article in a series on software team management. Since I'm remarkably bad at keeping to plans as regards blogging, please send your feedback and comments to assure me that you're reading and/or interested.

There are numerous things you need to get right to get a software team running smoothly. The first, even before a line of code is written, is to ensure that multiple developers can actually work on the same project without tripping over each other.

This boils down to a need for:

  • A copy of the code for each developer.

  • A separate server / development area for each developer, where the code can be run.

  • Some way of managing and re-combining the changes that developers make in their individual areas.

Or in other words, sandboxes, virtual servers, and version control.

Now, there are dozens of ways of laying out sandboxes, a range of web servers, and quite a few version control systems.

I'm not going to try and cover all these combinations. In this series, I'm going to try and provide one working solution to each of the project team's requirements.

The solution I'm going to cover here uses Linux, Apache, Samba, and Subversion.

You will also need some dedicated hardware which, given the flexibility of Linux, can just be a spare desktop machine, wiped and with Linux installed. Most distributions give you a "Server", "Web Server" or "Internet Server" option at install time which generally installs all these requirements. Personally, I tend to use Ubuntu as I'm most familiar with it, and it makes most of the installation procedures I encounter pretty easy.

I'm not going to tell you (right now, at least) how to install the LAMP stack or recompile PHP, as those are fairly well-documented and generally procedures. (OK, PHP recompilation can be non-trivial, but you can usually just install a package. While I will include some config fragments and instructions, you'll usually need some familiarity with the tools, or at least access to their help files.

What I will do is suggest how to set up your sandboxes, virtual hosts and development tools.

In this model, each of your developers will keep a copy of the project code in a common location in their home directories. They can then map, or mount, their home directories to their desktop (Windows, Mac or Linux) machines to use their favourite editors™ in the OS of their choice.

I suggest you lay down the location in which the project lives; keeping it the same for all developers makes debugging a lot easier. I suggest a path of ~/projects/projectName (in unix systems, '~' is shorthand for "a user's home directory".

To get started, and for testing purposes, I also suggest you create the folder ~/public_html, and the file ~/public_html/index.html which can just contain the text "Hello World, this is username's directory."

First, you need to mount the drives to your developers' desktops. On the server side, this means Samba needs to be running, and the [homes] stanza in /etc/samba.conf is enabled (ie, not commented out). Let's assume that your server is, known on the network as devbox (you'll also need to set this in samba.conf as "netbios name", I believe).

To mount a Samba share in Window, go to the Explorer (the file explorer, not IE), then tools => Map Network Drive. Choose a drive letter (eg, H: for Home), find your network on the server, and select its "homes" share. Assuming your linux usernames and passwords aren't the same as on your windows network, you'll also need to click the "Connect as a different user" link and fill out the details. (It's possible to co-ordinate accounts and passwords, but it's far too complex to cover here). The user's home directory should now be their H: drive.

To mount the share as a volume in OS X, go to the Finder, then Go => Connect To Server..., and type in smb://devbox/homes/ . Hit the [+] button before connecting to store that link as a favourite. Then hit connect, and supply username and password. The remote share will now be available (usually) as /Volumes/Homes/

To connect in Linux, find someone who uses Linux as a desktop machine, 'cos I haven't done so in years.

Now, find (or create) the public_html folder, and see if you can open index.html in a text editor. If you can, and can save it, you've got a dev area. It's not a sandbox yet though...

For the next step, you'll need apache running with mod_userdir enabled. If you're at the linux shell as root, and you're on an ubuntu or debian server, take a look in /etc/apache2/mods-available . userdir.conf and userdir.load should be in there. Assuming it's not already running, you can enable the module by typing "a2enmod userdir" then "apache2ctl graceful" (translated into english: apache2-enable-module "userdir", then apache2-control-gracefully-reload-configuration).

You should now be able to visit the server in your web browser at (eg) and see the index.html you were just editing.

I'm also assuming, for the purpose of this setup, that you have control over DNS records for your domain or subdomain. Why? Because being able to assign a wildcard DNS record to your dev server makes setting up new virtual hosts and sandboxes much easier. For example, if you assign * to point to your dev box's IP address, then will point to that box for all variations on username and project. You can then use these dynamic hostnames in your apache configuration for each user's virtual development server.

Once you've got this set up, you'll need to create the apache virtual hosts that map (yes, the hostnames get big) to /home/bob/projects/uberproject/wherever/the/webroot/is. To do this in ubuntu, you create a new config file in /etc/apache2/sites-available/ that contains the following:

<VirtualHost *>
DocumentRoot /home/bob/projects/uberproject/wherever/the/webroot/is
</VirtualHost *>

Usually, there's a few more lines in there, but those are the critical ones to illustrate what we're doing.

If that file is /etc/apache2/sites-available/bob.uberproject.conf, you'll need to enable it: as root, do a2ensite bob.uberproject.conf, then apache2ctl graceful. If all's worked out, you can then visit in your browser.

What you see there will, of course, depend on the contents of your project / document root. "Hello world" is always a good start.

Having got our developer's personal web server running, we'll pause there for now. I'll return fairly soon for the second part of this article, in which I'll cover setting up a subversion repository and using it to synchronise changes between users.

Posted by parsingphase, 2008-07-05 20:33

Anonymous user



Contact Richard