This documentation is archived and is not being maintained.
Field Notes IT And Life Experiences
Andrew Shuman has been a developer, program manager, writer, and product unit manager at Microsoft for the past 10 years. He currently runs a team in MSN responsible for producing the platform for membership services.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
So here is the situation. You've been here before, a hundred times if not more. Your server worked perfectly, flawlessly serving up Web pages, photos from the company meeting, and departmental memos on cost-cutting measures. Now it hums at you the same as always, but pages are not displaying, password prompts are appearing where they shouldn't, other sites have complete open access when they should be locked down, and "file not found" errors are popping up everywhere. You sit, staring at the machine, feeling like you've lost your puppy. "But it was just working fine" you exclaim. You start the crusade to find out who did this to you: who wounded your pet server.
It turns out everyone has had a hand in it. Janet down the hall needed to run a quick test for some new code. Quentin wanted to compare his settings against your server. Robert tuned the performance configuration to improve his application's data access speed. Now what are you to do? How can you retrieve your most sacred machine from the grave?
Well, I'm happy to say that from the depths of hell comes good advice and good stories on how to protect yourself from harm's way. Invest in properly maintaining a setup application for even your surliest of server components. I realize you're probably looking at this page askance right now. "Setup? For server components? I just copy those files in there and start tweaking settings. Why waste time? Just get the damn thing running." Ah yes, I hear your words, for they are my own. Many times I would have said the same thing to a person, kicked him out of my office, and slammed the door. However, I have learned the error of my ways. Investing in deployment technology, even for my server-side components, has saved my butt.
My team depends on the Microsoft® Windows® Installer system (MSI files) to handle all sorts of server settings from virtual roots in IIS, to SQL configurations, to Web pages, to security. Anyone who has installed Microsoft Office or SQL Server™ has seen the UI for an MSI, where you can specify folder locations and application settings. For the IT professional wrestling with server components, this is where you can now specify the things that are unique for each topology where you might deploy your bits—for example, which drive to use, the physical server names, the connection to your database, credentials to run services under, and more.
Our deployment code was the first investment we made on the support tools for the MSN® services team. It took one developer about four weeks to upgrade a legacy system, based only on an obsolete installation document, to a fully automated deployment. The biggest problem was convincing the naysayers on our team that it could indeed be accomplished! The costs paid off very quickly by speeding up our deployment time and accuracy. Before the automation, our deployments were sorry affairs conducted in the middle of the night because they took so damn long and were impossible to test beforehand. Friday nights from midnight until 4 A.M. were reserved not for sleep, but for the grueling synchronization of server settings.
After the automation implementation, we had a simple checklist "Did you run the install script? Yes/No." Our deployments dropped from multiple hours to just minutes. Obviously, there are pains to go through. It is tricky to completely avoid having an installation document, and if you have a complex system, guess what? The deployment will still be complex. We have found time and time again though that the investment pays off and gives us a framework to then bring in new features like zero-downtime deployment to completely minimize customer impact.
The benefits of this investment are huge. Not only do you have a way to bring your servers back to a well-known state after someone stomps on them, but you can now manage testing in a far more predictable fashion. No longer are developers spending gobs of time making various servers work; they can write the deployment code once and then reuse it for testing as well as production. The code pays off again when you do a hardware upgrade, or if you rebuild a machine from the ground up.
I won't go through all the machinations of how to create an MSI as there are far too many great resources out there for you. MSDN® Online is chock full of articles, as is www.installsite.org. InstallShield and Wise offer third-party products to help any developer in creating their setup routines. So deploy and be proud that you did!