Stink Digital has only been producing websites and systems for a short time, and when I started the company wasn’t set up to develop code at all. This gave me a great opportunity to think about the ideal development environment to set up that would be growth-proof (we’re expecting to get bigger) and low-admin (I don’t like spending time on sysadmin).

Things I wanted to achieve with our setup were:

• Have an easily manageable development environment
• Have the development environment mirror the production environment as closely as possible
• Allow each developer to alter any code they like without fear of breaking things for others
• Let each developer get going on a project as quickly as possible
• Take as much pain out of deployment as possible
• Do as much as possible to ensure stable and quality code

To that end I decided to use a system I’ve used before, but to enhance it with some tools and scripts. The basic idea is that all development takes place on a webserver on our local network, within a virtual host specific to each developer and project. For example, working on our own website I had a project called stinkdigital, which I accessed at “http://stinkdigital.marcel.adam” (”adam” is our webserver’s Netbios name, subscribing to our “He-Man characters” naming convention ). Vincent would have his own environment at http://stinkdigital.vincent.adam, and we’d have an integration environment at http://stinkdigital.adam.

This does mean that there are a lot of seperate virtual hosts on the webserver, but I’ve written a nice little shell script that sets them all up automatically, given the name of the domain, the project, and any developer that needs an environment…

Next, each developer needs easy access to the code itself. We initially used Samba and NFS to share the parent of the virtual host directory on the webserver, with each developer mounting their own share. This means that I had a a share to mount from adam, containing my ’stinkdigital’ folder. Each new project goes on that same share, and is configured to have its own folder and virtual host.

So now each developer has a share mounted on their own machine, with code as accessible as if it were local, but executed on a managed environment set up to be mirrored with the production environment. Each project is a seperate folder on that share and each one has a virtual host root within it (each project’s root is outside the web-accessible root, for obvious security reasons).

We had a lot of speed issues with this setup (we’re all running OS X 10.5, and our dev servers are runnign RHEL) – which seem to be fairly well documented. After a lot of mucking about, I eventually found that using MacFUSE and particularly this binary, we could each mount our shares with sshfs; using this technique, it’s hassle-free and fast.

In my next few posts I intend to get into some of the aims and issues involved with the actual server setup to get code executing, backing up and automatically building.