Hotfix / Patch build & delivery approach

We are in开发者_StackOverflow社区 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?

---

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.