In my last post I concentrated on the development server setup, in relation to how each developer has an environment they can work in easily. This time I want to discuss the issues we’ve encountered and decisions we’ve made in setting up our systems to be resilient and as automated as possible.

Our overall philosophy for core tool/system choice is simple; we want to choose things we know work and work well, and things that will allow us to grow the team easily and without each needing month long training period.

To that end, we’re using Subversion for our code versioning (Git – my other main consideration – is a bit too new and would take too much of a sea-change in the way we’re all used to developing). Our PHP unit-testing software is PHPUnit, a member of the ubiquitous xUnit family, and we use Phing for our build recipes. I’ve actually played with a lot of different build managers and the like in coming to these decisions; they’re the tools that seem most widely used, best supported and most reliable.

Each developer has their own environment in which they work day-to-day. Once they are ready to commit (ideally several times a day, each time they have a new piece of code that works) they commit their working copy (which lives on the drive shared from the local webserver) to the repository. There’s a lot of extra work I would like to do at this point, but currently the commit triggers an automated build of the integration environment, handled by SVN’s post-commit hooks, a little shell scripting, and Phing.

The auto-build consists of a one-size-fits-all recipe being run to delete the existing environment’s root directory, export the latest HEAD of the right repo, copy it to a new directory and make the cache folders server-writable. The last thing in the recipe is a call to a secondary, project-specific recipe that’s contained within the project itself. This means we can easily do things like creating symlinks, changing permissions on folders etc as we need to, and the recipe itself is versioned.

We also then tweet a message to our group account (more of that in another post), so everyone knows what’s going on.

Once the integration environment is built, the integration database also has to be rebuilt (although I haven’t yet set this up), all the tests need to be run automatically (I did set this up, but the latest versions of PHPUnit and Phing – which everyone talks about as being great together – simply don’t work; PHPUnit either crashes or fails to run the tests. I’m hoping a new version fixes these errors as I haven’t seen anyone else having the same problems). I am also planning on implementing DBUnit as a further validation of the tests and any DB structural changes that have come through with the commit.

The idea is then to follow this up with reports being messaged to the group so that failed tests can be acted upon immediately; a requirement of the continuous-build environment I’m aiming at.

Once the last pieces are in place we’ll be a position to confidently replicate these build scripts for the staging and production environments, so that we’ll be able to push changes live very quickly and with minimal stress and risk!

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.