Skip to content

October 25, 2011

2

Deployment Blocker No. 8: Brew your own deployment tools

by Shelly Bird

The decision has been made that nothing out there can do your  deployment just the way you want it.  Your staff starts to construct a set of custom scripts.  It is fabulously successful: it does exactly what you want, and executives are terribly impressed with your custom tool.

Well, sort of, because the developer is still working on the new version which is going to solve a little problem the installers are having, and oh, there was an update to that component that broke the script, so they are working on that…

Stop right there.  Please.

Ten years ago, I might have agreed to this approach, after looking over the operation and making sure the team had the rigor and organization to keep the scripts up to date over time.  I have done a lot of custom scripts and routines to speed deployments over the years (and picked up a bunch from others, such as The Deployment Guys or the MicrosoftScript Center).  There is a certain pride of ownership.

But times have changed, and I now concentrate on keeping custom scripts to a minimum.  Deployment tools for Windows are extremely mature now, and I’ve yet to see a good  excuse to walk away from what is now freely available, in order to stubbornly brew your own.  Don’t get me wrong:  some coding is always necessary to get the deployment streamlined and to smooth out rough corners.  But the framework should not be built from scratch.  If there is a tool that does 90% of what you need, start with that and add the other 10%.  This is one case where it pays to resist your team’s more excessive creative impulses, or you will be on your own during the deployment, unable to compare notes with the rest of the world.

Why wouldn’t it be a good idea to have something that is custom molded to your needs, when you’ve got the talent to do it? Some reasons:

  • Custom-crafted code is hard to maintain, and difficult to take into the next generation.
  • Your talent can get hit by a bus tomorrow or more likely, leave for a better job.  Do you have full documentation? Can a brand new developer walk in and pick it up tomorrow?
  • Who is going to support this code? The help desk will have to be somewhat familiar with the installation routines when things break down.  And they will break down.  Never trust a developer who says there are no bugs in their code.
  • Who is going to test and QA this code as it evolves? It is extremely bad practice to have the developer do his or her own testing.

The better way:  Use the latest tools that are available and keep abreast of the upgrades to those tools.  Give the manufacturer of the deployment tool noisy feedback when you notice missing or clunky features.  Train your staff to use these approved tools to their fullest extent.  Be wary of anything that is leading down a path that is not being hiked by anyone else.  Push your staff to research the Internet heavily for existing scripts that have a track record, and utilize those wherever you can,to counter the “not made here” syndrome.  Invest in a packaging team instead of developers.  It is a much better use of your money.

This is part of a ten part series of blogs “Top Ten Deployment Blockers”

Advertisements
Read more from Uncategorized
2 Comments Post a comment
  1. Patrick S.
    Oct 31 2011

    Could not agree more with this. I’m the person who designed and built our Windows 2000 and XP automated deployment systems. Lots of custom scripting. When we started our Windows 7 migrations, I looked into Microsoft Deployment Toolkit (MDT). Now, almost nothing in our deployment is home-grown. Everything is done in a standardized way that anyone in our organization can take over and maintain. Also, when other organizations ask us for advice on their deployments, they can look at ours and know they can do it that way too.

    Reply
    • Dec 6 2011

      One of the things we have noticed is the folks who stick to their custom crafted solution are moving much slower and have much less success compared to those who have kept up with the latest (free!) tools.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: