Summary
This release primarily involves:
- ... high level items
- ... not too much detail
Progression
Status | Activity | Description | Duration |
|---|---|---|---|
| Identify release date | see Release Calendar | minutes |
| Schedule cloning | clone from prd to: pre, trn, and tst for after release; https://hi.service-now.com/ | minutes |
| Schedule code review | this should happen after initial handover and before release | minutes |
| Submit change request | Open a build/test change request in https://yale.service-now.com/, assign to | minutes |
| Start release document | Copy from template ServiceNow Release YYYY-MM-DD | minutes |
| Requirements freeze | Curate, then freeze requirements, providing estimates for each using estimator spreadsheet or equivalent | hours |
| Build phase work | Begin work in dev | days |
| Unit tests | Ensure all pushed to tst & unit tested | hours |
| Initial code freeze | Hand over initial requirements list for functional & QA validation in tst | minutes |
| Conduct code review | Shouldn't take long, just basic validation of approach and docs | hours |
| Defect fixes | Iterative follow-up work in dev, test for defect resolution | days |
| Finalize release | Identify changes & updates that are going/not going. Push to pre. | hours |
| Final code freeze | Hand over final requirements list for functional & QA validation, w/ regression, in pre | minutes |
| Go/no-go | Decide to push to production. | minutes |
| Production deployment | Push to prd. | hours |
| Production rollback | If applicable; follow ServiceNow Rollback Procedure. | hours |
| Notify stakeholders | send out email w/ summary status & link to release documentation, close out RFC and cancel clone requests, if rollback or no-go. | minutes |
| Target/Actuals | Deliver target/actuals using estimator spreadsheet or equivalent | hours |
Change Control
CHG####### once you open a change, link it here
Release Notes
https://yale.service-now.com/kb_view.do?sysparm_article=KB0000066
Documentation
| Info |
|---|
Detail is provided in the description. Full implementation detail is captured in the update set, which can be viewed (with admin rights) by drilling down into the links. |
Requirements/Defects
Requirement (Original Names) | Functional Tested? | QA Tested? | Dev Status Notes | Description |
|---|---|---|---|---|
Defect ### | | | dev notes here | cut and paste the description from QC; ideally we will automate this later |
Requirement ### | | | add other rows, blocks of defects as needed to make this all readable | blah blah blah |
Approved Updates
Update Set (Original Names) | Description |
|---|---|
|
|
...
- link to the updates sets
- make sure you're pointing to the production links, as those are canonical and more or less guaranteed to persist.
Manual Updates
- Defect ### - ...
- Requirement ### - list specifics sufficient for someone to reproduce (idempotent code or serialized data is preferable)