HOTFIX Description
...
To resolve that, a "hotfix" is developed in a separate branch. Created from the last PRD release (or point 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).
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
Code Block 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.
| Info |
|---|
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
Code Block 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.
- Notify the development team that the HOTFIX branch is available for them to work in
- Once devs the developers 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
...
| Info |
|---|
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
...
...
| title | Formal Point Release Adoption |
|---|
...
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, and TRN and DR after a HOTFIX is approved in SUP.
KFS Point Release
...
Set the Point Release version
...
| Code Block |
|---|
mvn versions:set -DnewVersion=<CURRENT_VERSION_#>
svn ci pom.xml -m "<SOME_JIRA_ISSUE> preparing version <CURRENT_VERSION_#> for tagging and point release"
|
| Info |
|---|
In KFS, there will only be one POM file to check back into the branch for tagging. |
| Note | ||
|---|---|---|
| ||
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.
Code Block 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"
| Note | ||
|---|---|---|
| ||
<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.
Tag the release in subversion
In Subversion, create a new Tag from the approved "hotfix" branch. Point Releases adhere to a 3-digit X.X.Y nomenclature.
Info 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
- 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
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
| Note | ||
|---|---|---|
| ||
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
Set the Point Release version
...
| Code Block |
|---|
mvn versions:set -DnewVersion=<CURRENT_VERSION_#>
svn ci -m "<SOME_JIRA_ISSUE> preparing version <CURRENT_VERSION_#> for tagging and release" |
| Note | ||
|---|---|---|
| ||
For RICE, doing the 'svn ci' command after version change should check in multiple pom files (parent RICE pom and child poms for other RICE apps) |
Tag the relase in subversion
...
Tag the release by issuing a remote SVN copy command or software like Cornerstone
| Code Block |
|---|
svn cp https://svn0.uits.uconn.edu/kuali/KFS/kuali/kr/uconn_kr_core/branches/PRD-HF https://svn0.uits.uconn.edu/kuali/KFS/kuali/kr/uconn_kr_core/tags/<VERSION_NUM> -m "<JIRA-#> comment" |
...
in |
...
. |
...
...
Build Jenkins job "PRD_RICE" using "Build with Parameters" and choose the new <VERSION_NUM> of the Point Release in the parameter drop-down
...
POST RELEASE PROCESSING
...
...
Ensure all JIRA tickets for the with fixed version <VERSION_NUM> are set to 'resolved' in the KFS and/or KRICE projects KPS project
Now 'release' the version inside JIRA by going to Project -> Version Releases -> "manage versions", and selecting 'Release' from the cog on the right hand side.