HOTFIX and Point Release Process

Owned by Former user (Deleted)
Last updated: Jan 07, 2016 by Benjamin Daniels
3 min read

HOTFIX Description

 

If developers are currently working on the next release version in trunk, and there is a 'hot' issue or feature that needs to be productive, it can't just be checked into trunk, because this would mean that when it moved downstream to Production it would take all the untested development work in trunk with it.

To resolve that, a "hotfix" is developed in a separate branch. Created from the last PRD scheduled release tag, that branch can be quickly deployed to SUP for validation, without taking any new developments along with it. The hotfix will need to be transformed into a "Point Release" and merged back into trunk once the deployment is completed (by the developer responsible for creating the hotfix code).

 

KFS HOTFIX Procedure

  1. Create a branch named "hotfix" from the most recently released Tag in the KFS code repository. If an old "hotfix" branch exists, delete it, and then create a new one.

  2. Notify the development team that the HOTFIX branch is available for them to work in
  3. Once the developers notify their work is complete, build SUP using the SUP_HOTFIX job in Jenkins
  4. Notify appropriate parties that SUP KFS has been built from HOTFIX so they can begin testing

 

Once the change has been signed off on in SUP, follow the Point Release procedure listed below on this page.

Once the CM begins the Point Release process, the developer(s) should focus on merging their changes from the HOTFIX branch back into Trunk.

Point Release Description

 

Point Releases are production releases of KFS that are not built from trunk. They are similar to regular KFS releases except they are built from a prior release tag and contain priority changes and/or bug fixes.

A Point Release is tagged and released into PRD, YE, SUP, and TRN after a HOTFIX is approved in SUP.

 

KFS Point Release

 

Tag the release in subversion

  1. In Subversion, create a new Tag from the approved "hotfix" branch. Point Releases adhere to a 3-digit X.X.Y nomenclature.

    A scheduled release would be tagged something like "3.4.0" and a point release due to a hotfix from that scheduled release would be "3.4.1", "3.4.2", etc

  2. The Kuali Development Manager should have created a specific JIRA ticket and Footprints RFC change request that can be referenced for the Hotfix/Point Release process.

 

Build Production and Prod-mirror systems in Jenkins 

  1. Build Jenkins job "PRD_KFS" using "Build with Parameters" and choose the new <VERSION_NUM> of the Point Release in the parameter drop-down

  2. Apply any .XML files or SQL scripts mandatory for the build. You should have received a list of these from the developer JIRA's leading up to the Point Release 

SQL and XML build files

Please take note of the special instructions on any JIRA where the "XML/SQL file for build" checkbox is ticked. Certain files may have explicit instructions such as being applied BEFORE the build, or a special sequence they need to be run in.

 

POST RELEASE PROCESSING 

 

Release The New Version in JIRA

  1. Ensure all JIRA tickets for the with fixed version <VERSION_NUM> are set to 'resolved' in the KPS project

  2. Now 'release' the version inside JIRA by going to Project -> Releases -> "manage versions", and selecting 'Release' from the cog on the right hand side.

     

    This can be checked by going to project -> Releases -> issues, see the breakdown in top right corner