Skip to main content

Implement a fix for the current production state

The process of urgent fixes for modules in the production environment follows the fix-forward approach, rather than rolling back the affected modules and reverting to the previous deployed state.

The following diagram depicts the maintenance process to deliver a fix or maintenance for the active release in production for the application. The process uses a release maintenance branch to control and manage the fixes. The purpose of the branch is to add maintenance to a release that is already deployed to the production environment. It does not serve the process to add new functionality to a future release, which is covered by the default workflow or the usage of an epic branch.

Git branching diagram with a release maintenance branch for the production maintenance process

If you only tagged a release...

If at the point you built a release candidate package you only marked a release with a tag and did not create a release maintenance branch, you can create that branch at a later time when you find you need it.

For example, git switch -c release/rel-2.0.1 2.0.1 creates a new branch release/rel-2.0.1 from git tag 2.0.1 on main and makes it the current branch.

When implementing a fix for the current production state, the development team works through the following tasks:

  1. In the event of a required fix or urgent maintenance for the production runtime, which in this example is currently running the 2.1.0 release, the development team creates a release/rel-2.1.0 branch based on the existing Git tag in the central Git server. The release branch is a protected branch and does not allow developers to directly push commits to this branch.

    • Note: In the diagrams for this workflow, the release/rel-2.1.0 branch is abbreviated to rel-2.1.0 for readability. Other multi-segmented branch names are similarly abbreviated to their contexts in the diagrams (for example, feature_1 or hotfix_1).

  2. For each necessary fix, a feature branch is created according to the defined naming conventions hotfix/rel-2.1.0/52-fix-mortgage-calculation, represented by the hotfix_1 based on the release/rel-2.1.0 branch. This allows the assigned developer to have a copy of the codebase on which they can work in isolation from other development activities.

    Branching diagram focused on the hotfix_1 branch created from the release maintenance branch for release 2.1.0

  3. The developers fetch the feature branch from the central Git repository into their local clone of the repository and switch to that branch to start making the necessary modifications. They use the user build facility of their IDE to vet out any syntax issues. They can use a feature branch pipeline to build the changed and impacted files. Optionally, the developer can prepare a preliminary package, which can be used for validating the fix in a controlled test environment.

  4. The developer initiates the pull request process, which provides the ability to add peer review and approval steps before allowing the changes to be merged into the release/rel-2.1.0 release maintenance branch.

  5. A Basic Build Pipeline for the release maintenance branch will build all the changes (and their impacts).

  6. The developer requests a Release Pipeline for the release/rel-2.1.0 branch that builds the changes (and their impacts), and that includes the packaging process to create the fix package for the production runtime. The developer will test the package in the applicable test environments, as shown in the following diagram.

    Branching diagram showing the Release Pipeline generating a fix package from the release maintenance branch

  7. After collecting the necessary approvals, the fix package can be deployed to the production environment. To indicate the new state of the production runtime, the developer creates a Git tag (2.1.1 in this example) for the commit that was used to create the fix package. This tag indicates the currently-deployed version of the application.

  8. Finally, the developer is responsible for starting the pull request process to merge the changes from the release/rel-2.1.0 branch back to the main branch to also include the fix into the next release.

  9. The release/rel-2.1.0 branch is retained in case another fix is needed for the active release. The release maintenance branch becomes obsolete when the next planned release (whose starting point is represented by a more recent commit on the main branch) is deployed to production. In this event, the new commit point on the main branch becomes the baseline for a new release maintenance branch.

Last updated on