Developing a hotfix starts with building (and testing, to whatever extent you feel is warranted) a solution in your hotfix development project and committing it to your hotfix branch:
Just like regular development, your code will need to pass basic unit tests and compliance checks before it can be promoted. This requires the use of a Continuous Integration pipeline specific to the hotfix branch. Just as the regular development project has a CI ‘twin’ project, so does your hotfix development project. This is labelled ‘DEV_HF_CI’ in the illustration below.
The CI build plan will deploy the hotfix changeset to the hotfix CI project and execute your unit tests and compliance checks, resulting in the tagging of the commit in the hotfix branch. This commit tag, which identifies the commit as a release candidate, will use a value which indicates the name of the hotfix branch (based on the Main branch from which it was spawned) along with a unique identifier for the commit within that branch. In the diagram below, for example, release 44 from the Main branch is being fixed in the automatically created Hotfix-44 branch. The first commit to this branch which successfully passes CI is tagged ci-44.1. Note that the specific pattern of this naming scheme varies between build system, depending upon the capabilities provided by each platform, but the principle remains identical.
It is possible that the first hotfix build does not pass acceptance (it does not actually fix the problem, or there is some other issue) in which case there would be an additional build, tagged ci-44.2 .
Once the developer is happy with a hotfix candidate, (ci-44.2 in this case) they can invoke a deployment pipeline which will deploy the latest tagged release candidate asset immediately to Production. More accurately, the mettleci datastage deploy (documentation) call in the deployment pipeline will act to synchronize the Production environment with the software configuration represented by the hotfix branch (Hotfix-44, in this example). Because this branch reflected the state of Production when it was created the only changes that get deployed are those made in the Hotfix-44 branch since its inception.
Once deployment is complete, the Production environment can considered to be at release prod-44.2 (since this is production release 44 with the second commit from the hotfix branch Hotfix-44 applied to it.
Once a hotfix change has been deployed to Production, the next step is to incorporate this change back into your Main branch so that it is included in subsequent releases.
The traditional approach of using a Git merge will not work with DataStage, as your DataStage project is a shared working copy of your Git repository. Do not be tempted to adopt a branch merging approach as you will have no easy mechanism for resolving merge conflicts.
The simplest and most effective approach to integrating your hotfix changes back into your Main branch is to manually re-apply them in your development project associated with your Main branch. Once these changes are committed to Git they progress along your regular delivery pipeline, including all the testing processes they would have skipped during hotfix deployment.
