Application Deployment Tip #4: If it Doesn't Work, it Wasn't Tested
"The operation was a success, but the patient died." -- Unknown
Maybe it is just me who confuses unit testing with functional testing. I see functional testing as running the entire application, moving from one task to another. When I say unit testing, I refer to testing a process from start to finish and including as many variations as reasonably possible. Sometimes that process goes beyond the boundaries of the code I am writing. In those cases, I follow it through with either the other components involved in the process or surrogate methods for those components. The surrogate methods mimic as much as possible the functionality of the final components (since a surrogate should be used only when the real thing does not yet exist or is not yet accessible). Many people think of unit testing as testing a single method with a single value, while some consider unit testing as successful compilation. I have even worked with a few who consider their work done if their IDE doesn't raises any errors before compilation.
For the purpose of getting home at a reasonable hour (or at least being able to leave without keeping others late), let's use my definition. This means that every piece of code needs to be tested as thoroughly as practical before checking it in to source control. Failing to do so will result in the code breaking the system at some point -- worst of all, just about the time it becomes critical, when it will be very hard to find.
Application Deployment Tip #6: Perform Dress Rehearsals
"No battle plan survives contact with the enemy." -- Colin Powell
The best learned lessons are those hardest won, and those that are won twice are learned perfectly or never at all. I have written out perfect, step-by-step instructions for deployments that went off without a hitch. I didn't have to fully validate those plans except in my own mind once or twice. Unfortunately, one of those instances occurred early in my career and it took a few dinners (followed by late night snacks) in front of the monitor to figure out what had gone wrong. I finally decided that for the rest of my career I was going to walk through my plan from start to finish before the go-live -- even if I was 100% confident in it.
The dress-rehearsal is great because you do all of the things you will do for the "real" release only without any of the stress of users and bosses and bonuses waiting for you to finish. And if you find that you missed a step in your plans or a step is not detailed enough, it is much easier to address that earlier than late at night.
Application Deployment Tip #7: Context-Specific Is OK
During those earlier years I developed habits that got me home on time. When I found that simply having those habits myself was no longer enough, I worked on codifying them into documented processes. Since the habits themselves had formed organically rather than through a conscious process, the documented processes tended to be very context-specific. While I have covered the broad strokes of what is applicable to most (if not all) application projects here, I strongly recommend enhancing and elaborating the application deployment process to specific applications, projects, enterprises or teams (as best fits your delivery culture).
In addition to all the reasons already stated, there is one other reason to have a plan for deployment and follow it: if you have to work late, tired hands and a frustrated mind are much more likely to create more mistakes, and sometimes bigger ones, too. All of the lessons I referenced are real and personal. They kept me away from friends, fun and family before I discovered the application deployment processes to control how late I had to work to deliver what users expected and deserved -- so that they could go home on time, too.