Kuali System Change Management (SCM)

Owned by Former user (Deleted)
Last updated: Feb 05, 2015 by Former user (Deleted)
2 min read

Configuration Management 

 Kuali CM

 

Environment Builds

Emergency Builds

Emergency fixes follow a similar SDLC process as that employed for regular changes. The reporter of the productioin issue must validate the applied fix in a near-to-production environment before the change is deploymed to PRD.  The greatest differences between the standard change process and an emergency fix lies in the the use of the environments, the flow of the change through those environments, amd the speed with which the entire change cycle is completed.  An Emergency Change Order (eCO) must be submitted to the CAB <link to CAB> for the purpose of notifying the help desk and creating a record of the unplanned change.

The SUP environment is used for emergency/hot fix testing following the below process

  • Following a data refresh of the SUP environment the reported bug is verified and recreated
  • The HotFix branch in SVN is created from PRD
  • A fix is developed in the chosen developers local environment and then checked into svn, into the TRUNK
  • DEV is rebuilt from TRUNK and the developer validates the change
  • Upon successful validation of the code in DEV, the change is merged into the SVN HotFix branch by the CM
  • SUP is rebuilt from the SVN HotFix branch
  • The Reporter of the issue (bug) validates that the fix has eliminated the issue
  • The fix is merged into the SVN PRD branch and PRD is rebuilt from it
    • Regression testing will be performed to the extent possible without significant delay to the fix (Automation of the existing test scripts will make more robust regression testing possible)
  • The HotFix Branch is deleted from SVN

Post-Fix (does not have to be immediate)

    • the CM merges the fix into the other SVN branches (TST, UAT) and rebuilds those environments from their respective SVN branches rendering all environments "fixed".
    • All in-process work in TST & UAT must be appropriately addressed:
      • all changes to TST that were successfully unit tested prior to the bug fix and not yet deployed to the UAT environment must be re-tested
      • all changes to UAT that were validated and approved for PRD but not yet  deployed must be retested by the requestor

Benefit to bypassing TST & UAT on Emergency fix to PRD

  • none of the work in process that is present in TST & UAT will interfere with resolving the production issue
  • SUP is also the closest environment to PRD and intended for this and troubleshooting

Challenges of bypassing TST & UAT on Emergency fix to PRD

  • once the fix is introduced in downstream environments, the work in-process that is not yet present in PRD may negatively impact the fix applied and additional work may be required
  • the bug fix may negatively impact the work in process causing re-work to those efforts  

Emergency Build Process

 

Scheduled Build Process

Kuali Planned Release Schedule

Kuali Change Process Flow

Tools

Resources

How-To's