A post I wrote for a previous employer in July 2008 was useful for a lot of people they said, but it disappeared. So, I've added it back to my own blog from my archives and re-posted.
This post has come in handy for me time and time again. There aren't really any changes from the original. Also, I've been working on a very interesting project lately that might have inspired me to revisit this article as well.
10 Simple Rules for Launching a Web Site
While not all web site launches are simple. The vast majority of releases are actually not that complex either and a few simple rules and processes can keep things easily on track and on time.
This article is not necessarily a detailed article about developing a website. It's also not exhaustive in it's scope. What it is though are some basic things that can help keep projects on track and moving in the right direction. It is about getting a production bound web application online with as little trouble and heroics as possible. I will assume you did a good job in development and wrote good solid code that has been unit, function, and regression tested as necessary. If you didn't, you're not so ready yet so do that first before you go live.
Rule 1: Start deploying to production as soon as possible. Don't Wait till the end.
Deploy Often and Early to your production environment. This will help you avoid building a site that runs great in development but not at all in production. Once your prototyping is done, you have your basic features or framework built, and you're happy just start deploying to production. Why almost no one does this is beyond me. I suspect it's usually to save a few dollars up front on hosting fees or due to the misconception that everything will just be fine later. You are not developing your website to sit on a squeaky dev server in the closet for the next 18-24 months are you? Develop and deploy for production.
Rule 2: Create a scripted and repeatable build and deployment process.
Automate your deployment/build process. If you are using FTP and clicking anything more than once or twice you are probably doing it wrong. Your deployments should be scripted, repeatable, and stable. And, they should have a ROLLBACK plan! Deployment itself should be relatively painless when done right. Now, painless deployment doesn't necessarily mean that what you deployed will work. That's a different issue.
Rule 3: Use Source control. This is not optional.
Use Excellent source control. Note, I did not say complex. I said excellent. That means you have some concept of a stable release in your source control system and development process. That means you can keep right on working on the next release while your current release goes live and lives it's life. I recommend Git or SVN in most cases for various reasons. I'm very much leaning toward Git these days overall but talking people into using is something else all together. Why are people so afraid of change?
Rule 4: Issue Tracking. This is not optional.
Use some sort of formal issue tracking system. If you are being asked to do something that does not have an issue logged, you should not be working on it at all. Occasions where this is not true are very rare. There are many fee hosted, free, and commercial packages available depending on your budget and inclination. Personally, I really like JIRA at the moment.
Rule 5: Create a launch plan.
No matter what you did to get to beta and how shameful or awesome it was put it behind you now. Those times are over! If you don't want you site to go live with a whimper you need a lauch plan from at the very least beta forward. This is a plan at the granularity of about 1/4 to 1/2 day of what needs to be done, who's responsibility it is, and that is reviewed periodically to keep it all on track and keep people honest. What you call this and the meetings around it depend on your methodology and inclinations. But, the plan is the plan.
Rule 6: Create a Launch Checklist
Launch Day Checklist. The time seems imminent. The clock is ticking. The board and investors have very serious (or worried) looks on their faces. Your code seems to be in pretty good shape. Launch is immenient. It's time to make a launch checklist. It's a simple thing really. It looks something like the following example.
Task # Time Duration Responsible Human's Name Task Description Complete (Y/N)
Done right, this will be accurate to the MINUTE and it's what you'll use as a go-live checklist to keep people from doing anything stupid on launch day and keep everyone on the same page across your entire team. It's also a great tool for whomever is filling the project management role as it will help them spot trouble almost as soon as it comes up. If you have individuals with one or more tasks that span more that 2 hours, that task should probably be broken down in to smaller pieces if possible.
Rule 7: Practice your launch checklist with one or more mock launches 1-4 weeks before go-live. Do this as many times as necessary and get it right to get ready.
Mock Launches might seem like an extravagance. But, they are actually an overall time and sanity saver. Remember when I said deploy often and early? This is part of that. Grab your launch checklist and run through it exactly as if you were going live; minus cutting over your real DNS of course. The first time it probably won't go all that well. But, that is exactly the point you'll learn what you didn't even know you didn't know. The second time, you'll know if you are ready or not. Make sure you build these into your schedule and don't ignore them.
Rule 8: Have a roll back plan
You should never do anything to your production environment that you can't somehow undo if necessary. This is a rule and it should rarely be broken. Being forced to move forward because you cannot go back is a world of all night stinky conference room six hour conference call pain and usually makes bads thing even worse. Have a roll back plan for your code, your database, your everything. Don't forget about people. Rollback plans can help protect you and your staff from pointless heroics.
Rule 9: Do not be afraid to abort and reschedule. No-Go.
It's launch day. You should now be very prepared. You made your list and checked it twice with mock launches but something is not going right and you are off by a couple of hours. Still have the courage to say say no-go. That's right. Unless someone is literally going to die if the site doesn't go out the door a small delay isn't usually that big of a deal. Don't torture people by keeping them up all night because the whole team missed something key on the launch check list or something changed. You should be rewarded, not punished for finding and dealing with problems in a mature way. There is no reason to make significant changes to an already tested and production ready RELEASE BRANCH within 48 hours of a SERIOUS launch. If you find yourself really needing to do so, then, you did something wrong and your schedule probably already slipped anyway and you feel like you're going to throw up all over your desk; sorry. Check your launch checklist. If you're doing, being asked to do, or wanting to do a bunch of stuff that is not on that list then something is very wrong. You missed something important. Abort and reschedule.
Rule 10: Celebrate!
That's right. You probably just busted your ass to make all this happen. Don't forget to celebrate your success!