ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

Thursday, October 4, 2007

Deployment AntiPatterns

I recently came across a blog post from ScottGuthrie (MSFT) titled Tip/Trick: Automating Dev, QA, Staging, and Production Web.Config Settings with VS 2005. In his tip, Scott uses his build automation to produce multiple product configurations that stage different servers with different web.config files. He then gets dozens of ataboys comments from readers including one who wonders if this could be done for Winforms applications to which Scott replies
Yes - you should be able to use the same approach with winforms projects.


Now I'm sure Scott is a smart .NET developer, but this type of `xcopy deployment` that is tightly coupled to build automation is crazy. Furthermore, I know he's not alone in this thinking since if you pick up practically any .NET book you won't find deployment covered until the end of the book and even then it's a cursory look at VDPROJ as if deployment is that simple.

Build ( Core Code and Installer Packages ), Installation and Configuration are NOT the same thing. They are distinct steps in an overall process of deploying an application.

You may very well need to do all three of these steps within a single transaction ( for example automatically deploying an application to a Dev Integration Lab as part of a CI process ) but the steps are still separate.

Now some people disagree on whether an Install should actually configure a product or not. Regardless the build output should consist of a setup package. If you want to automate the deployment the build should then call staging automation to apply the package. If the package contains configuration logic, the staging automaton should pass those values to the package. If not, the staging automation should call an external utility and pass the values so that the product is ready to be used. In this way the staging automation could be invoked multiple times to stage Dev, QA, Production, whatever.

Scott's solution might be `OK` for an in house application that only gets `deployed` to a limited no of locations, but if you are working on a real `Product` that gets sold and given to customers all over the world you will really want to make a proper investment in automation.

No comments:

Post a Comment