Working to a structured development process

You might work on small projects or large scale developments, you might be the only person involved or you might work with many others, regardless of your situation, having a structured development process is essential.

I work for the University of Leeds as a generalist designer/developer, a recent project of mine has been upgrading our institutional Content Management System to the latest version of the software, a task which had an extremely tight timescale which was met by using a structured development process.

My toolbox

So let’s set the scene, I work within the Central IT Services’ Web Team and am the technical lead for the University of Leeds’ corporate website (www.leeds.ac.uk), this site runs on top of the Jadu Content Management System and was launched in September 2009. We have just performed a major upgrade of the core Jadu CMS which was turned around in a very short space of time, and it’s this upgrade project which is the basis for this post.

University of Leeds (www.leeds.ac.uk)

For those of you wanting to know which apps and tools I use, here’s a quick rundown:

  • iMac 21.5″ 3.2GHz Intel Core i3
  • Textmate
  • Terminal
  • MAMP (local Apache/MySQL server)
  • GIT (Version Control System)
  • Trac (Project Management and Issue Tracking)

Project management tools

There are a whole host of tools available which will allow you to manage your project, both free and paid-for. Within the Web Team, we use the Open Source ‘Trac’ Project, Trac may not be the prettiest piece of software ever written, but it’s extremely flexible through a plug-in architecture and being open source, we’ve moulded it to fit our exact needs as a team. The key features we use are issue tracking, milestones and source code management.

“There are a whole host of tools available which will allow you to manage your project, both free and paid-for.”

As well as using Trac internally within our team we have opened up access to a couple of teams within the institution who work with us on the corporate project. The Central Communications team (Comms), for example, have the ability to assign and manage tickets, see the commit history and timeline and read the wiki, but don’t have access to the source code repositories or source browsing facility through Trac.

local > staging > production (aka develop > debug > deploy)

There are three separate environments which I use to develop for leeds.ac.uk. Firstly, all of the code I write is done on a local server which runs a complete standalone version of the code and database. This allows me to mess around as much as I want without any risk to the live site and database which runs on the production server where the live version of leeds.ac.uk lives.

In between my local development server and the production server is the ’staging’ server, this is an identical environment to the production server (even running on the same physical hardware) and is accessed through a private URL. By running this staging server I can deploy code for the team to test, confident that this is identical to how the site will operate once deployed to the production server.

The deployment is handled through the GIT version control system which is tied to our Trac system where we maintain a central source code repository (even though it’s not strictly needed with GIT, we still maintain a central repo for ‘disaster planning’), code is pushed from Local to Trac, then from Trac to Staging and ultimately from Trac to Live.

How it all tied together

During the upgrade project I worked with our internal project co-ordinator and the Comms team to define a set of milestone dates for the project, such as ‘testing’, ‘pre-launch’, ‘launch’ and ‘post launch’.

We knew the date the site had to launch by was concrete, so worked backwards from there, with the pre-launch milestone set to the start of the week of launch, this contained any issues and tasks that needed to be completed before we could possibly go-live (such as a last minute content-freeze and migration from the currently live site to the upgraded site). Finally, the post-launch milestone allowed me to keep any tasks that weren’t directly related to the launch to be processed afterwards.

“We knew the date the site had to launch by was concrete,
so worked backwards from there”

We had a thorough round of testing in the weeks running up to launch, the task of testing was performed by Comms who were testing against a ‘release candidate’ build on the Staging server. They worked for a week going through every single page on the Release Candidate build and logged tickets for any bugs, whether they be for differences in layout or differences in content. This is a critical step and their eagle eyes spotted a wide range of issues, from missing/out of date content, to the fact that the breadcrumb trail was 2 pixels further to the right than it should be.

These issues were all classified against a simple priority scale:

  1. Blocker (the site can’t possibly go live until this is fixed)
  2. Critical (if this isn’t fixed, people may die)
  3. Major (it’s a big problem, but no-one’s going to die)
  4. Minor (this needs fixing at some point)
  5. Trivial (no-one would probably notice except us)

“a ‘critical’ issue may be seen as one which would cause the institution to cause severe confusion or lose money”

If you were to take into account the business considerations, a ‘critical’ issue may be seen as one which would cause the institution to cause severe confusion or lose money (such as printing an incorrect emergency phone number). Not all content is created equal, so a content difference on the Press Releases page might be classed as ‘Major’ while a page buried in the bowels of the site with a spelling error might be classed as ‘Minor’ or ‘Trivial’. It’s worth sitting down with the people who are going to be creating most of your tickets and defining what your priorities are to make sure that everything is not logged as high-priority to try and get them finished quicker.

(Based on this project I may move to remove the Blocker priority, as nearly all critical issues could be considered blockers)

I left the team alone for a week to perform their testing, only stepping in to fix any Blocker/Critical issues which would hamper their testing efforts and being on hand to answer any questions they had, after they were satisfied the entire site had been tested, their access to staging was revoked while I worked through all of the tickets assigned to the ‘Testing’ milestone. This process took 3 days for a couple of hundred issues, once the reported issue had been resolved the ticket was re-assigned to the owner for them to recheck the issue, and for them to close the ticket if it was fixed, or fail if it was still present.

Make your tools work for you

I am lucky to work with some extremely talented people, including a colleague who installed and maintains our Trac instance and implements some of the weird and wonderful ideas we have to make it more useful for us. One of the most used tweaks was to use the post-receive hooks of GIT to allow us to modify tickets based on the commit message.

For example, I accept Ticket #356 which requires a code change to resolve. I make the required change to the code and commit this to my local repository with the following command:

1
git commit -m "Fixes #356 - bug was caused by ... and fixed by ..."
When I next push my changes to Trac, the post-receive hook recognises the ‘Fixes #356′ part of the commit message, adds a comment to the ticket linking to the specific changeset and diff showing exactly what changed, and sets the ticket to ‘testing’ status, which then fires off an email to the ticket owner prompting them to test the fix and close the ticket if it’s resolved.

I also communicated the progress of the project with the testing team by highlighting which version of the code the staging server was currently running:

Code version

This linked through to a summary changelog, which gave an outline of what had changed from version to version, clicking through would list precisely what had changed in the code and which tickets were fixed:

Trac changelog

We projected the Trac roadmap screen in our office with an auto-refresh which let us watch the testing milestone gradually reach 100% completion as the Comms team signed off the fixed tickets (I’m a sucker for visualising the size and progress of the task). All of this communication regarding the process of the project was passive, it was only available if and when anyone needed to see it.

Projection of project progress

### In conclusion

It doesn’t matter what tools or software you use as long as you’re able to make them fit around the way you work. If a piece of software gets in the way of how you work then you should seriously consider either changing it, or (if possible) changing the way it works to better suit your needs. If you’re working with other people on a project, communication is essential. By keeping everyone involved up-to date you can reduce the amount of time needed for meetings and reach that magical milestone, getting sign off.

comments powered by Disqus