Summary
This release primarily involves:
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
Release Notes
https://yale.service-now.com/kb_view.do?sysparm_article=KB0000066
Documentation
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 |
|---|---|
|
|
...these are examples. The important things:
- 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)