[wix-users] Versioning for Continuous Automated Builds

[Edwin Castro]

Decomposing your LARGE installer into smaller chunks is not a trivial thing
to do and it completely depends on what you are installing. Suppose you are
installing an IIS website with a bunch of virtual directories representing
different portions of the site (perhaps different bits of functionality...
features?) and perhaps a bunch of web services (more features?) then you
could possibly take those physical units which likely were decomposed into
features internally in your LARGE MSI into separate products (MSIs).
Perhaps the LARGE MSI has a bunch of features but not all the features are
installed on a given machine. Perhaps each web service feature is installed
on separate web server VMs separate from each other so that you can
independently scale a given web service depending on need. That kind of
organization suggests a separate products (MSIs) for each web service.
Perhaps the database itself is a separate MSI since databases are typically
installed once per environment while the web services and web sites are
installed on multiple computers. Perhaps you could separate the database
schema from the initial database data. How exactly you go about this
depends on the system you are deploying.

I remember reading a while ago that you had to deploy tons of source code
files. There are times when you want the code to be compiled just-in-time
and in that case you really want to install the source code files. I would
bet it would be much easier and smaller to compile the source code files
into assemblies and install the assemblies instead very likely reducing the
number of files you need to install. If you already do this then don't
worry about it.

Once you have a bunch of MSIs they need to be installed, potentially
separately, onto the target machines. IF it makes sense to have something
that looks like a single installer where you select which features
(products) you want to install on a given machine, then you can create a
burn bundle with a custom bootstrapper application to make those decisions.
Of course, if the MSIs are going to be deployed to a bunch of machines
using something like puppet, chef, or even System Center Configuration
Manager, then you could simply use those systems to assign and install the
appropriate MSIs on the appropriate systems.

The details of what you can do really depend on the overall architecture
for the system you're deploying.

As it pertains to managing product guids, I would say "Don't manage product
guids". You want to implement major upgrades anyway and for that you need
your product guids to change every build so set your Product Id="*".
There's nothing to manage there. If you use a burn bundle, then it has it's
own guid that you should keep as Id="*" so that it changes every build too
just like for the normal MSIs.

One piece of advice, if you successfully partition the entire system into
smaller installable components, then consider having separate builds for
each installable component where the end result of that build is the MSI
for that installable component. Then you can have a build for "the
aggregate of everything" (the burn bundle) that consumes the MSIs from the
other builds. Notice that the larger and more complex the system the larger
and more complex the build system becomes. You'll likely want a dedicated
build engineer for this or at least somebody with build engineering
experience that can advice in how to architect complex build/CI/CD systems.

--
Edwin G. Castro


On Tue, May 29, 2018 at 9:36 AM, Ven H <venh.123 at gmail.com> wrote:

> Wow. Words of wisdom blended with experience, expertise and so much
> humility. Thanks a ton, Edwin, for that awesome and detailed explanation. I
> would like to take it further. When you say divide your package into
> smaller packages, can you please provide some more details on how to
> achieve it and how to manage manage product guids, upgrades and so on for
> all the packages together and what will be the points to keep in mind. If
> you could please provide some more details on how to go about, I would like
> to take it further.
>
> On the next part, I personally prefer Option 1 and I will tell my customer
> to go with that. So, can you please provide some more details about that as
> well?
>
> Regards,
> Venkatesh
>
> On Tue, May 29, 2018 at 7:31 PM, Edwin Castro <egcastr at gmail.com> wrote:
>
>> I'd recommend you always create and release major upgrades. In my opinion
>> that is the easiest to manage. That said, I think I remember you saying
>> once that your msi package was very, very large. Deliverying a large msi
>> package whenever anything changes might be overkill in your case. You might
>> then consider dividing your package into smaller packages you can deliver
>> independently from each other.
>>
>> Be adviced that a "patch" is a packaging option and not a type of
>> upgrade. For example, you can deliver a major upgrade via a regular msi
>> package OR a patch. I don't have practical experience with patches because
>> I avoid them so take the next opinion with a huge grain of salt... I
>> conceptually think that patches really don't mesh well with the concept of
>> continuous integration. A patch conceptually requires two msi packages to
>> create a "diff" from. In a continuous build scenario you need to be able to
>> answer the question of which msi package to use as the base msi package and
>> you can't answer that question effectively until after your first release.
>> In any case, you still need to create the "new" msi package for the "diff"
>> so I think it is always better to create major upgrade msi packages in
>> continuous builds and "manually" create patches when you actually need them
>> for a particular fix or customer. When I said "manual" above I meant
>> "automate the patch creation process so you can simply input the two msi
>> packages to 'diff' and manually invoke that script when you need it."
>>
>> For versioning, the only requirement is that your ProductVersion have
>> only 3 components less than the maximum: 255.255.65535. Note if you have a
>> 4th component, then the 4th component is ignored. I'd always set it to zero
>> as a reminder that it is always ignored.
>>
>> The type of upgrade dictates if you must change ProductVersion on every
>> build or not. For example, if you want to build major upgrades on every
>> build, you must change the ProductVersion on "every" build but you really
>> have two options.
>>
>> Option 1: always change ProductVersion. This allows you to test major
>> upgrades even from unreleased continuous builds in development. A very
>> useful tool but you do use up your available version numbers so that could
>> be a problem if you have a lot of continuous builds between releases.
>>
>> Option 2: change ProductVersion between releases. This allows you to keep
>> things simple as you can just keep the ProductVersion hardcoded and change
>> it only at the beginning of a new release. The downside is you can only
>> test major upgrades between a previous release and the current continuous
>> build since the ProductVersion is not changing from continuous build to
>> continuous build.
>>
>> We follow option 1 and we pass in our versioning information through
>> DefineConstants so the version information is available as preprocessor
>> variables. Let me know if you choose option 1 and I can provide more
>> details if you need help.
>>
>> --
>> Edwin G. Castro
>>
>>
>> On Tue, May 29, 2018, 06:15 Ven H via wix-users <
>> wix-users at lists.wixtoolset.org> wrote:
>>
>>> We have a requirement to generate MSI for automated builds. So, whenever
>>> code check-ins happen in SCM (this will also involve changes in Database
>>> scripts which have to be executed, IIS changes, registry changes, GAC
>>> changes, COM registration  etc. in addition to files), Jenkins will
>>> trigger
>>> a job at regular intervals by polling for changes in SCM. When this job
>>> runs, it has to create MSI. I have a couple of questions related to this.
>>>
>>> 1. Should I create a Patch or a Major Upgrade or a Minor Upgrade?
>>> Honestly,
>>> I am not sure how to create a Minor Upgrade though.
>>>
>>> 2. How should I manage versions in this case?
>>>
>>> Please help with your inputs.
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>
>