HOTFIX and Point Release Process

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 release (or point 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).

The HOTFIX/PR procedure is different for KFS versus RICE. If the change is in KFS, only follow the KFS procedure. If the change originates in RICE, follow both in tandem, performing the steps in the RICE procedures first.

If you run the svn commands via CLI, they require a valid Kerberos Ticket , and can be run from any machine. Since all of the below commands only issue remote instructions to the SVN server, you can run the commands from any machine because they don't modify anything at all locally.

KFS HOTFIX Procedure

Create the KFS hotfix branch from the most recent Release/Point Release tag

svn rm https://svn0.uits.uconn.edu/kuali/KFS/kuali/kfs/uconn_kfs_core/branches/PRD-HF -m "JIRA-ISSUE-KEY deleting prior hotfix branch"

svn cp https://svn0.uits.uconn.edu/kuali/KFS/kuali/kfs/uconn_kfs_core/tags/<LATEST_PRODUCTION_VERSION> https://svn0.uits.uconn.edu/kuali/KFS/kuali/kfs/uconn_kfs_core/branches/PRD-HF -m "JIRA-ISSUE-KEY updating the hotfix branch to version <LATEST_PRODUCTION_VERSION>"

Notify the development team that the HOTFIX branch is available for them to work in
Once devs notify their work is complete, build SUP KFS using the SUP_KFS_HOTFIX job in Jenkins
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.

RICE HOTFIX Procedure

Create the RICE hotfix branch from the most recent Release/Point Release tag

svn rm https://svn0.uits.uconn.edu/kuali/KFS/kuali/kr/uconn_kr_core/branches/PRD-HF -m "JIRA-ISSUE-KEY deleting prior hotfix branch"

svn cp https://svn0.uits.uconn.edu/kuali/KFS/kuali/kr/uconn_kr_core/tags/<LATEST_PRODUCTION_VERSION> https://svn0.uits.uconn.edu/kuali/KFS/kuali/kr/uconn_kr_core/branches/PRD-HF -m "JIRA-ISSUE-KEY updating the hotfix branch to version <LATEST_PRODUCTION_VERSION>"

Notify the development team that the HOTFIX branch is available for them to work in
Once devs notify their work is complete, build SUP KFS using the SUP_RICE_HOTFIX job in Jenkins
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

Formal Point Release Adoption

This is a new process being tested and adopted as of October 15th, 2013

Point Releases are production releases of KFS and/or RICE that are not built from trunk. They are similar to regular KFS and RICE 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, TRN and DR after a HOTFIX is approved in SUP.

KFS Point Release

Set the Point Release version

Check out a local copy of the KFS hotfix branch
Change the version in the pom.xml file to the Point Release version number

mvn versions:set -DnewVersion=<CURRENT_VERSION_#>
svn ci pom.xml -m "<SOME_JIRA_ISSUE> preparing version <CURRENT_VERSION_#> for tagging and point release"

In KFS, there will only be one POM file to check back into the branch for tagging.

Adjusting <rice.version> manually

If the RICE version is also getting a Point Release, then make sure you adjust the entry <rice.version> in the POM. The Maven 'newVersion' command won't find or change this, and you need to remove '-SNAPSHOT' from it manually using a text editor like VIM or Nano.

Tag the release in subversion

Tag the release by issuing a remote SVN copy command, or using software like Cornerstone.

svn cp https://svn0.uits.uconn.edu/kuali/KFS/kuali/kfs/uconn_kfs_core/branches/PRD-HF https://svn0.uits.uconn.edu/kuali/KFS/kuali/kfs/uconn_kfs_core/tags/<VERSION_NUM> -m "<JIRA-#> comment"

<JIRA-#> must be a valid JIRA issue key. A specific JIRA ticket should have already been created to release KFS and RICE. If not, create one now!

Create new JIRA version

Kuali Project manager creates a new JIRA version, usually incrementing the patch portion of the previous release number (major.minor.patches). Assign this new version as the 'fixed version' of any JIRA tickets going into the hotfix release.

Build Production and Prod-mirror systems in Jenkins

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

RICE Point Release