What procedures do you do before releasing web software?

Question

I create a lot of websites that are fairly large database driven applications. The development time on these can be anywhere from 3 months to a year+. Given the variety of scripts and languages as well as the number of browsers used in web development, what sort of checklist or pre-launch procedure do you use to ensure nothing gets missed before the big unveil.

Answer 1

Great question, my company has been building such a list, most of it is specific to what we do though, very custom to our type of apps. However theres a lot of basic stuff, like make sure both domain.com and www.domain.com work in the DNS, and the whole reason we put that check on our list was because we launched a site that only www worked, and the client was linking to it with no www prefix.

So basically, open up a word doc, start entering items to it. You don't have to make a list all at once because you wont think of everything, Instead make it more of a living document, add to it and modify it as you go. After a few run throughs the list will become more mature.

Answer 2

Dan Zambonini recently posted his website launch checklist: http://www.boxuk.com/blog/the-ultimate-website-launch-checklist

Answer 3

(I'm not sure if your question was directed at successful deployment from an operations point of view, or from a features/user experience point of view, so I've assumed operations)

I'd first try and avoid going three months to a year+ without deploying the site. Ideally, it would be deployed automatically, to a staging server (maybe for developers to see, hopefully for the product owner to see, ideally for the end users to see). This kind of deployment would happen every day, or at the least every week. When you actually go to "production", your deployment process should be completely perfected.

I'd suggest the following links:

• Have an automated deployment
• The Joel Test
• Continuous Integration
• Release It

That said, we'd usually build a deployment guide (a wiki page or formal documentation) that describes how to install and monitor the site. Here are the things I like to see in these documents:

Architecture

• Do the people deploying it understand the logical and physical architecture?
• What in production differs from your test environment? Ensure it's documented and tested. Is there a firewall or load balancer? Make sure you know exactly what needs to happen to make that work.
• What third party services does your application depend on?
• How will your application behave when they are unavailable? If services need to be reset or manual intervention is needed, make sure it's documented.
• What levels of tracing/logging do you have? Is there a health monitoring strategy? Is there a backup if your first level of logging fails?
• Have you done capacity planning?
• Have you performed a load test?
• Have you done a security audit?

Operations

• Do you have a clear list of service accounts/logins and permissions required? They can take a while to acquire. Make sure to have everything ready before you go.
• What monitoring options do the support team have?
• What troubleshooting options do the support team have?
• What common problems/solutions do you anticipate?
• Do you know ahead of time how operations will perform backups and monitoring? Will they be using separate NICs/networks? Do you have any bugs that accidentally involve you binding to multiple IP addresses?
• Make sure your backup and restore process is documented and tested.
• Have the operations team been trained on which performance metrics to watch and how to react?
• Are your logs backed up?
• Are your logs going to an easily accessible place? Can you access them quickly? Are they easily consumable?
• Are you using rolling logs? 3GB log files are not nice.
• What should the maintenance plans on your databases include?

Process

• What is your deployment window?
• Will this be a big bang or rolling deployment? Will it affect all users or just a segment?
• What will users see in the mean time if they visit the site during deployment?
• Have you warned users about the downtime?
• What is your rollback strategy if (or, when) it fails?
• If the deployment fails, how long will you persist trying to fix it before rolling back?
• Is the entire thing scripted. Production deployment is an important event that takes planning, but it should still only involve two mouse clicks.

But I can't stress enough the value of getting this process in place from day one, and testing it every single day.