There's a few expressions I like to use: (Fair warning, these are cynical and/or sarcastic)
- Entropy is a bitch
- Once is an exception, twice is a pattern
- Death but a thousand cuts
- What's the problem with a little poo in the installer.
- Garbage In, Garbage Out
- Fix the installer and not the application. That's a great idea.
Every one of those things is a broken window and frankly, I don't allow broken windows. Unfortunately, that doesn't always make me a very popular person because developers are often quite self-convinced that their solution is acceptable.
So back to my initial comment about unit tests failing builds. For installs this is Windows Installer validation and I suggest custom ICE's to enforce quality standards. I suggest writing tests that enforce your coding standards. Don't allow selfReg? Write an ICE that checks the SelfReg table. Don't allow InstallUtil CA's? Write an ICE that scans for those. Allow only sanctioned DTF custom actions? Write a unit test that reads in a white list file and make sure only those custom actions exist.
Enforcing standards through automation is the best way to fight entropy that I know.
8 comments:
Chris, I largely agree with your post here, but i'm interested in one of the items you specifically call out - osql. We use SQLCMD, which is by and large the same.
I understand the rationale for the rest - don't implement something as a CA which is going to require its own unique transactional behavior when MSI can do that for you.
But sadly, MSI doesn't provide you with anything for SQL - we've found it to be an entirely roll-our-own process. Granted, I can use a managed CA instead of SQLCMD, but I perceive that as shades of grey on the same ultimate problem. If there's something large we're missing out on, enlighten the masses, please! :)
I don't know what tools you use or what database engine you are connecting to so I'll just say in our environment we use InstallShield to handle our SQL Script processing. Basically they are well tested data driven custom actions written in unmanaged code and support MSSQL, Oracle and MySQL. WiX provides a similiar concept except that they only upport MSSQL.
With InstallShield the IDE exposes the concepts of SQL Connection/Requirements, SQL Script and SQL Text Replace. This maps to 7 custom tables that allow you to describe the SQL story for the installer.
I call these types of patterns 'quasi-standard actions' as the infrastructure is developed and maintained to high standards by someone else. I only have to focus on the details related to the setup I'm working on.
http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/SQLServer.htm
http://wix.sourceforge.net/manual-wix3/sql_xsd_index.htm
So basically I would change your rule to include things that your tools can do for you not just what MSI can do for you.
I also largely agree with what you said IF everything "further down the process" is dependent on what has been built "upstream" in the build process - and that may be the actual scope of your build process.
Where I'm at now, the install build is separate from the core product source code builds. It contains both Windows Installer packaging builds, the generation of Linux RPM and tarballs, as well as the creation of ISO and download files. Our build engineers don't want me stopping the entire build because an MSI package doesn't build properly. They want the entire build to run to completion and then report all build failures so that the MSI, Linux, and media portions of the build are always run. Basically, they don't want an MSI break to stop the build process and potentially hide the fact that there's also a problem with either the Linux or media portions of the build that wouldn't be found otherwise because an "upsteam" part of the build stopped the overall build process.
Chris, thanks. We use SQL 2008 and InstallShield, but we actively stay away from anything proprietary, to the point that we'd rather roll our own that find out we have vendor lockin - at least, beyond MSFT.
I guess I'm a little confused by the proprietary comment and the fact that you use InstallShield to build the install. It seems like you are saying we'd rather not have functionality that we paid for because one day we might want to use something else so instead we'll just go write our own and pay for it twice.
Eitherway The WiX SQL stuff is ultimatly just some custom actions and custom tables so it's really easy to 'borrow' it and use it inside InstallShield. It's FOSS so shouldn't be any concerns there.
My thought against using the InstallShield CA's for database tasks is that it creates a new system (and point of failure) that not everyone understands.
My preference is to use the same tool that developers/technical support/etc. are using to build the databases so we're all able to troubleshoot any issue.
We built a custom, relatively easy-to-use tool in managed code that I call in a managed CA, but if the process is a batch script that calls SQLCMD I would use that in 'black box' form to avoid having InstallShield have its tentacles in yet another area.
Well, you do have a pattern so that's good. Now imagine someone coming up with a competing pattern and then injecting it into the MSI. How would you feel about that? :-) That's kind of the real point of this post.
Chris, what I mean by proprietary is that we use installshield primarily as a way of manipulating the MSI. Should we choose to go to Wise or even WIX, we could do so without the baggage of having to find a replacement for any vendor's IP (again, other than MS). What one sees as paying for twice, another sees as insurance. :)
Post a Comment