Software Deployment

People cut their own because every company has different needs, different environment, etc.

In defining our package & deployment standards, I started out by listing the reasons why you are moving to an MSI architecture in order of importance. Then that was translated into specific packaging tasks that would achieve those goals while maximizing efficiency by eliminating relatively unimportant functions.

For example, there is a lot of mix & match of packages here. Conflict Management requirements are strict.
We're a highly secure, lockdown environment so QA testing requirements include being functional at all levels of security rights.
Our machines have a 13 hour maintenance window with high bandwidth, so speed of individual installs is a low priority. Each install could take 12 hours to perform and I don't care so long as I can launch the generic install on several thousand machines at once. There are no requirements for upgrading / patching / modifying, only Install, Remove and Repair are used.

Your results will vary. Determine strict requirements in order to achieve your goal while eliminating as many manual or unimportant steps as possible..

Interesting! We also have similar requirements from our customers with more moderate security needs which dictate what sort of overall strategy we may adopt. However, at the detailed level, do you attempt to document each file installed, each registry item set and reset etc. or do you let the installer developer to work this out from the files in a staging area?

In the past, the project teams have produced a detailed install spec listing everything which had to be done to install the product down to the detail. Is there an alternative to this approach? I am wondering if the spec should be more tabular with templates for files, reg extries, .NET assemblies etc. which can be translated more or less one for one into an MSI installer database via the developer.

Regards, Tony

We're a wise shop, so keep that in mind when reading my response.

Unless you are an extremely secure environment (as in Dept of Defense) I would not bother documenting every file, registry key, etc. I import all tables into my conflict manager and retain a backup of development at 4 different stages, plus the final release. There is a lot of querys & reports built in, and being a SQL database it is possible to create custom queries and reports. If there is concern as to what a package contains, the issue will be bounced back to the packaging team and they'll just open up the archive and look. If there is a question about a particular file on a machine, it can be backtracked through Conflict Manager or even through that machines registry to one or more MSIs. Backtracking through the registry is cryptic, but possible.

I would make a detailed install spec listing what should be done to produce a package. The reason is that often packaging consultants are brought in and because every environment has different needs/priorities, if it isn't laid out for them then they will probably retain the priorities of their previous environment and not yours. In Wise, this is normally done with the creation of a process template, a step-by-step to do list. There is a description in each step, where priorities can be clearly documented. You should have a process template for each type of package you produce, such as "Repackaged Legacy SETUP.EXE", "Transformed Vendor MSI", maybe a "In-House Developed" process if you take special steps with that.

It sounds like you may want to export some of the above into some other report or document, but documents like that should all be built from your conflict database and process templates. That's what's really important, everything on top of that is a matter of convenient organization or executive summary.

Oh, another thing that effects our strategy is that we are an in-house packaging team. If you are consultants and you only provide your customers with a final product, you might not want to provide your customers with your entire conflict database and development environment. Then the detailed "package contents" reports might be preferable. We don't have to worry about that, so our full development archive is more than enough documentation.

When it comes to packaging, there isn't a one size fits all process. Custom tailor one to suit you.