views:

59

answers:

2

We are in the process of adapting our build & release procedure of one of our Java based products to support patch / hotfix releases.

Today, we deliver a full installation package (which is a set of RPM packages wrapped in an ISO) out of our build pipeline. However, we aim to also support incremental / more fine grained upgrade / patch shipments as well.

To keep things simple as an initial step, we plan to have more fine-grained RPM packages and package a subset (only the changed ones in the scope of a release) of these RPMs in a dedicated hotfix ISO along with the full installation ISO. (We have also considered other options like binary diff - delta RPMs - creating a separate hotfix RPM etc.)

I would like to hear about how you manage your build pipeline - packaging and version control (as this is in the core a release management issue as well) in order to support this kind of hotfix deployments?

+1  A: 

I would like to hear about how you manage your build pipeline - packaging and version control

I introduced a (working) concept:

A Bugreport as an identification like bug711 all sources touched to fix this bug will be tagged (Version Control) with the bug report no.

This tag can be used to checkout all sources required to create a patch (In cases static files like html,js,css etc. are involved) and to merge from branches into head revision.

In the case of java code the minimum to deploy would be an artifact (jar,ear,war-file). Which requires a restart of the application. In case of JBoss Application Server we discovered that the 'exploded' deploy allows us to patch without downtimes.

It really depends on the server environment and the kind of applications which approach would work best for you. I'm afraid that there is no single best-practice.

stacker
As far as I understand you collect all changed binary artifacts in a Java deployment unit. Is this Java jar/war is the same unit as you would have in a regular build, or is it really patch specific? If it is patch specific then how do you make sure that the artifacts in that jar go to the right place in your JBoss exploded directory?Another tricky thing is then how do you track which patch is installed on a customer system? (We use RPM versions and a dedicated file to track this)
Erdem
Patches contain only a few files to fix a bug. Jar/war are build the same way as the whole version (70+ artifacts) and placed in a version repository. To fix a bug only the relevant files will be installed, less work for QA. Patches are build automatically by checkout with bugreport # and tracked in a db. (test,release,install...)
stacker
A: 

Stacker - how do you handle multiple patches that affect the same sources?

Dante617
In our case (although we never worked on 2 patches at the same time), each patch has a separate codeline. Normally all code changes from a previous patch are propagated to the next patch codeline. However, I would say if you work on 2 patch codelines and their delivery dates are conflicting then it would be best to isolate these 2 codelines (Assuming changes in one patch are not required for the other one - otherwise you need to merge the changes in 2 patch codelines anyway).
Erdem