wayne on May 8, 2008
Just yesterday I changed my theme from Cogitation to Leaves and after checking out the site this morning I realize that I never really gave the site a full review after making my changes. I noticed that when viewing an individual post, the post is wrapped down under the end points of the two side bars. Not good.
You would think that I would know to do this, and in fact, I normally do. Being this site is personal, and I work it when I find time or need a distraction, it doesn't always get the full "deployment treatment".
What do I mean by that? A few things actually. When you deploy a web site, you need to check your site afterwards to ensure that it still looks and behaves the way you intended. Bugs can sneak into your code in the most innocent of ways, and the effects of the bugs can range wildly. That is why it's good to review your site after making changes, not only where you have made changes, but everywhere else as well.
With that said, I thought I would list the various things a developer would need to check before and after deploying a web application.
Before Deployment
- Ask yourself, are there any structural changes to the site that would break external links? Updating the site and changing the structure of folders and page names can really mess up your inbound links. Attention should be paid to those if you care about them at all.
- Is there going to be a downtime on the site? If your site has a significant amount of traffic, are your changes going to impact your end-users by causing a brief or extended outage? If so, you may consider alerting them to the impending changes and letting them know for how long the site may be down. You can also circumvent this by deploying your changes when the site is at a low traffic period. For WayneJohn.com, that is nearly anytime right now, but weekends and evening periods are generally a great time to deploy a web application without impacting most of your users. The web site logs will contain the info you need to make this determination.
- Thoroughly test your changes locally or on a staging server. Pre-launch testing is critical. You can't make changes and expect them to work all the time. Some changes are pretty minor, but should still be given some testing to ensure one hasn't mucked up something else. I've found that having a non-developer type person do some testing helps to find some of the quirks better than a developer would. Developers already understand what's going on behind the scenes and that translates into different actions during testing, whereas a person that doesn't understand what's under the hood will do things their own way, and not necessarily how you intended.
- Are there any database changes that need to be accounted for? I've found myself in the position where I've made changes to a database to create some new functionality only to finish up the web site code weeks or months later. It would be easy to forget about those database changes made long ago. There is nothing quite as humbling as releasing what you think will work, only to find you forgot some stored procedures or forgot to modify a table in production as part of the deployment.
- Do the changes add new pages or sections to the site? If so, you might want to have your sitemap updated prior to launch. This is the beauty of having your sitemap generated automatically. I would still check it out to ensure it still works as expected.
- Disaster recovery, always leave yourself a way out. Make your deployment reversible. Nothing is worse than not having a way to return the site to its original state after a failed deployment. With to number of things that can go wrong, it's wise to leave yourself a way back. There are many ways to do this, and perhaps that is another post.
- Document the deployment steps. This can be critical if the deployment requires more than one person. Even a single person should document their steps in case they get sidetracked during the deployment. Having a roadmap of the steps and process you will take will ensure some thought is given to the process and also leave you a roadmap to simply follow along to.
After Deployment
- Test, test test. Test some more. Finally, test one more time. The extent of the changes to your site will determine the extent to which you would need to test your deployment. If your changes are minor and not far reaching, say like changing a font or color, then this is going to be really quick. But what if you are changing the flow around a e-commerce checkout process? The changes you make are going to have a much greater reach, potentially outside the entire area you are making changes. Test test test, I cannot say that enough.
- Document your changes and close the project. Larger projects may require that some documentation is performed after the launch. I find it helpful to have some documentation on the changes made and the deployment steps taken. I keep these outside of the web project itself in a 'deployments' folder. This is not to say that your code should be any less documented, but rather this is supplemental to that.
- Inform the interested parties. After the web site is deployed, it's best to have another set of eyes review the changes and perform their own testing. Also, it's nice to be able to tell the site owners that their requested changes have been implemented, and they work!
Not every web site will need to adhere to such strict guidelines for a deployment, but some will. Each site will have different rules and ideas about what is necessary for the site, it's owners and visitors.
These are some of the things I consider before deploying any of my clients web projects, as well as my own. Albeit, my personal sites like this one take a back-seat from time to time.
What would you add to these two lists?
