The following fields will be removed with the new workflow changes :
- UAT Status
- Customization Status
- KFDM Customization Status
- KFDM UAT status
Existing Customization Status | New Workflow Status | Comment |
---|---|---|
Requested | OPEN | |
Requires Review & Prioritization | OPEN / REQUIREMENTS INCOMPLETE / REQUIRES PRIORITIZATION | |
Requires Approval | REQUIRES PRIORITIZATION / AVAILABLE FOR ESTIMATION / AVAILABLE FOR ASSIGNMENT | |
Assigned | TO DO | |
Development in Progress | DEVELOPMENT IN PROGRESS | |
Development Complete | DEVELOPMENT COMPLETE | |
Unit Testing Complete | DEVELOPMENT COMPLETE | Enter : XML/SQL Required for Build? |
Deployed to UAT | READY FOR QA / QA IN PROGRESS / READY FOR UAT / UAT IN PROGRESS | Enter : Fixed Version |
User Accepted | USER ACCEPTED | Replaces UAT Status = "Passed" |
User Rejected | DEVELOPMENT IN PROGRESS | |
Deployed to Prod | READY FOR PROD / CLOSED | Enter : Resolution = "Fixed" |
On Hold | BLOCKED |
Below are the deprecated legacy instructions :
This table describes the standarad operating procedure for JIRA usage. Following procedure is imperative, because the automated merge tool anticipate that this procedure has been followed:
Status | Resolutions | UAT Status | Customization Status | Assignor (who sets the status and assignee) | Asignee (after status set) |
Open | Unresolved | None | Requester | <decided based off of KFS component>** | |
Open | Unresolved | None | Assigned | Technical Manager | Developer/Technician |
In Progress | Unresolved | None | Development in Progress | Developer | Developer |
In Progress | Unresolved | None | Development Complete | Developer | Developer |
In Progress | Unresolved | None | Unit Testing Complete | Developer | Developer |
In Progress | Unresolved | None | Deployed to UAT | Developer | Requestor |
In Progress | Resolved | Passed | User Accepted | Requestor/tester | Developer/Technician |
In Progress | Unresolved | Failed | User Rejected | Requestor/tester | Developer/Technician |
Closed | Resolved | Passed | Deployed to PRD | Developer/Technicin | |
Open || In Progress || Re-opened | Unresolved | Any | On Hold | Developer/Technical Manager | Developer |
Pre-Build
Verify that all Jira’s owned by you (you are the assignee) reflect the proper values for selection by the automated tool:
Jiras going to PRD should always have a fix version assigned that corresponds to the next planned release.
- Fix Version must = next release
- Jira should be Resolved
- Customization status must be “User Accepted”
- UAT Status must be “Passed”
Jiras going to UAT
- Jira must be Unresolved
- Jira must be “In Progress”
- Customization status must be “Unit Testing Complete”
- Are there external file dependencies for deplyment/build? If so set the checkbox & paste svn link to files in JIRA comment, along with instructions & dependencies for execution fo the CM.
Post-Build (any environment)
Verify that the changes and all their dependencies have arrived in the target environment
Verify that any required SQL scripts have been executed without error
Verify that status field values
Post deplyment - PRD – please make sure you take the following actions
- Verify that changes have arrived and are complete (may need to work with requestor)
- Set status to “Closed”
- Verify that customization status is set to “Deployed to PRD”
Post deployment - UAT– please make sure you take the following actions
- Perform a unit test to verify that the changes and all dependencies are in place.
- Verify that the customization status is “Deployed to UAT”
- Assign the Jira to the requestor providing comment informing them that the change is in UAT and ready for their validation. Also tell them the date of the next scheduled PRD build so they know what their target completion for testing is.