Relaunching Olympic Holidays

Posted on 27 September 2010 by Pete Duncanson Tweet

One of our biggest projects for the year finally went live in September. The sitewide update of our long term client Olympic Holidays. Here's a bit more on the scope of the project, how we managed it and how deploying it went well due to a lot of prep work.

So, roughly 4 months after we started the process of a sitewide overhaul to Olympic Holidays the site went live at the end of September. It's important to stress that this wasn't actually a redesign, more a sitewide overhaul of old, out of date code and markup to give us a much improved working base for the site.

I'd like to cover a few of the processess and bits of software we used to manage this project.

Dragging the codebase up to date

To give an idea of the scale of the update, we had over 400 bug/feature/update cases logged in our Fogbugz case management software and the update impacted on over 600 files stored in a Kiln repository for the website and booking engine.

The main project aims for this update were:

• Update the homepage to allow standard promos to fit in new grid layout
• Standardise typography across the site by removing as many old/redundant rules as possible (over 120 different font declarations!) without changing the look and feel too much.
• Remove a number of old (table based) layout elements - again, without changing the overall look.
• Optimise XML and XHTML template logic wherever possible

Project and task management with Fogbugz

As you might imagine, with over 400 cases logged for attention ranging from small tweaks to graphics through to combining typography rules into a single stylesheet we had to be smart about how we managed the workload.

We work closely with the Olympic team and as such, we all log work into Fogbugz but we had to establish a clear set of milestone cases we could post into first otherwise you end up with a jumble of cases that appeared on their own and utterly out of context and with no clear workflow to stick to.

We opted to use the nesting that's available within Fogbugz to create a number of "parent cases" with clear descriptions, milestones and estimates for completion then logged cases within the parent but left the parent empty.

This means you can easily expand the listing to see all the cases, key milestones can be quickly reviewed and closed off when complete.

Fogbugz also gives you a number of admin settings to create "projects" so we also made extensive use of these but kept to only 4 or 5 active projects at a time (eg "Big Developments" "Code optimisation" etc).

Setting a date

You'd be amazed when working on a big project with a lot of people invested who all have a say, all log bugs and requests and notice different things about the site that need attention how any dates you try and set can suddenly become rather "flexible" at best.

With the best will in the world, you can set a date early in the process to relaunch but sometimes the realities of working on such a multi person project mean you've got to roll with it a little and be flexible.

As long as everyone is aware that continual development means continual testing and the date disappears over the horizon then I don't see any major issues as long as the workload is effectively managed and you're using Fogbugz/case management correctly.

Freezing code

The important part is that you do reach a point where you freeze code and then as with the screenshot above, push all requests into a "post launch" project.

We were happy that each case we worked on was testing while it was being addressed and then again, twice, before launch so code freeze for us often means a couple of days on a project this size because we know the site inside out and also because we've got a large team constantly eyeballing and running tests on a daily basis so freezing code is more a practical concern so we can bundle everything into a deployment script which can then be tested ready for roll out.

Often a client will think post launch is some mythical date far away in the future. The reality is once you've frozen code and stopped development to run final tests, "post launch" is actually only really the next day once you've launched.

Success!

We launched the updated design for Olympic at the end of September and in all honesty, it went better than we could have imagined! Reviewing the cases we had logged, not one issue was reported that was a problem related to the relaunch.

We had a total of 32 post launch "bug" cases for a site update containing over 600 file modifications. Not one of those was caused by the relaunch and were mainly a result of effectively increasing the testers to company wide by letting all the staff know a new version of the site had gone up!

Script based deployment

I'm leaving you at this point, I've done the case management bit. Pete will be writing a follow up post about how we (he) managed the deployment of all those files to a number of load balanced servers so stay tuned.