Launch day is one of the scariest and most stressful times in web development. Getting everyone on the same page in terms of what’s going to happen and when it’s going to happen goes a long way in making the entire process smoother.
Things are less likely to go wrong and people are less likely to start throwing recriminations around if the processes for deployment and dealing with issues are well documented.
The following is a list I’ve been building up in my notes of some of the things that should be done in preparation for launching a new site or major revamp.
- Site and content has been signed off by appropriate people.
- Any potential downtime and exact release times have been confirmed and communicated to everyone involved. Involved means everything from developers to people in marketing who organised that snazzy TV promo.
- Everyone knows who’s in charge of what and where notifications need to go for any immediate problems. This process is organised with designated communication points so that the deployment team don’t get flooded with notifications if things go wrong.
Look and Feel
- Images have appropriate Alt Text for both accessibility and SEO.
Pages have sensible Titles.
Pages have Appropriate Meta Tags.
- Favicon is in place.
- Friendly error pages, particular 404 and 500 error pages.
- Contact Us page has appropriate details.
- Copyright info is in place.
- Someone has gone through checking for spelling and grammar errors etc.
- At least some manual testing has occurred to catch any outstanding issues, e.g., weird edge cases or black text on a black background.
- Backups are running at appropriate intervals and the steps that are needed to recover using them are documented.
- Transfer DNS at an appropriate time. Make sure something is in place to handle delays in propagation.
- The “www.” subdomain is redirecting appropriately, or the reverse if you prefer www. domains
- Monitoring service is checking site uptime (Pingdom or similar).
- Something is capturing application errors and reporting them (A service like Airbrake or something better than the default system logging).
- Deployment process is automated, fast and takes one click or command. You need to be rolling out quickly and any fixes need to be able to go out fast and reliably as well.
- Set up resource monitoring (Munin or similar).
- Make sure the site comes back up after power cuts/crashes.
- Penetration testing if necessary. Level of security testing should be agreed well before launch as it will affect release schedules.
- Analytics are in place.
- Larger sites have a sitemap.xml for bots to read.
- Automated tests are in place. The level of automated testing being used should have been decided early in the project.
- Testing has occurred across browsers that are being supported. Browser support decisions should have been made at the beginning of the project.
- Devs know what the expected release load will be and they have resources in place to handle it.
- The site should be load tested for the expected load. At the very least, it should be checked with reasonable load for any performance anomalies.
- Set up a robots.txt
- Run a website performance tool such as Yslow over the site.
- Put a catch-all email address on the domain.
- Wrap-Up and review meeting with the team.
- Write a case study and/or take some pictures to add the site to your profile.
Did I miss anything? Leave a comment and tell me about it.
(This post cross-posted from my blog)