Configuration Management

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

Data Refreshes

DBA SLA for Refreshes

Standard schema refreshes scheduled through Control M = same day turnaround. These refreshes are designed to use the PRD export created overnight every night. Therefore no DBA action is required.
Schema refreshes that require manual intervention from the DBA team = 24 hour turnaround following receipt of RIP.

Example:

Data refreshes requiring data from export other than current day's.

Refreshes requiring retention of the attachments table (DR for example)

Log

Date	Target Environment	(PRD) Source backup date	Requestor	Reason	Form
05 Jan 2015	TRN	05 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 1.docx
05 Jan 2015	SUP	05 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 1.docx
07 Jan 2015	YE	07 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 3.docx
06 Jan 2015	UAT	06 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 2.docx
06 Jan 2015	DEV	06 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 2.docx
07 Jan 2015	DR	07 Jan 2015	Pam K	Post month end refresh	Jan 5 2015 Refresh KFS Environments Request - part 3.docx

Requirements

Environment	PII Script Execution	Encryption following PII scripts
DEV	Yes	Yes
TST	Yes	Yes
UAT	Yes	Yes
SUP	No*	No (data already encrypted from import)
TRN	Yes	Yes

*Backdoor access in all environments is now controlled by permissions in KFS. Only those granted this permission via management authorization have the ability to utilize backdoor access. All sensitive data is encrypted in all instances so only those with the proper credemtials or permission for backdoor access will have visibility to encrypted data.

Before a UAT refresh is performed, please ensure that no failed batch jobs have created orphaned processes on the UAT.BATCH server. These processes will be owned by KFSCTMUSER or "505" and can interfere with the refresh procedure. Please notify the CM or SA to check this if you are unsure whether there are orphaned batch processes present.