...
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 principal intent of creating a hotfix branch is to support the delivery of time-critical changes to Production whilst avoiding the need to halt ongoing development of new feature and non-time critical defects in your development codebase.
| Note |
|---|
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. |
...