Photo: https://flickr.com/photos/unseelie/766346338/
How many steps does it take to get a change live on your website?
Ideally it should be a one click process.
Otherwise, when the pressure is on (i.e. when there is a bug on the site that you quickly need to fix) you’re sure to forget some critical step and make an even bigger hole for yourself.
What we called “the deployment process” changed a lot during my time at Trade Me.
In the very early days we just copied ASP scripts directly onto the production server. We only got away with this because there were not many people writing code and there were not many people using the site.
Later, as we moved to having multiple web servers which each required a copy of the code, we created a simple Windows application which copied the files from our local directory onto each of the web servers and would also execute selected SQL scripts against the production database. This was much better, but still relied on the developer doing the push to have the correct files on their local machine.
As the site got bigger there were some new complications. For a start there were more people involved. The teams responsible for testing and for maintaining the database and servers got increasingly nervous about developers having the ability to push code at any time. The code base got bigger, making it more difficult to keep in sync. The number of people using the site increased massively, making it less and less practical to just put code changes multiple times during the day. And, we also moved to using ASP.NET, which added the complication of having a build step in the process.
To address some of these issues we developed a new tool we called the “Release Manager” which hooked into source control and allowed us to package up changes so that they could be pushed to test or to production with one click (using simple NAnt scripts under the covers). This removed a lot of the complexity and stress from the process.
I’m sure it has continued to evolve since I left - if anybody from Trade Me is reading it would be interesting to hear about how you do it now.
Towards the end of my time there the test team, who had final sign-off on each release (twice per day at that point), got into the habit of queuing up ‘Push The Button’ by the Sugarbabes on the MP3 player when they were ready for changes to be deployed to production. Every time I hear that song now my pulse increases slightly at the prospect of some site changes going live!
I always thought it would be fun to wire up a proper red button to trigger the deployment, but never got the time :
If you’re interested, I wrote a little more about the tools and processes we used (as at April ‘07) here:
Questions from Tim Haines, Part II
How do you manage deployment?