Deployment Blocker No. 8: Brew your own deployment tools
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”