Release Procedure
Sprint Progression
This isn't a precisely linear process because it involves feedback (see above diagram), but it represents the general order.
Status |
Activity |
Description |
Duration |
---|---|---|---|
() |
Submit change request |
Open a build/test change request in https://yale.service-now.com/, assign to |
minutes |
() |
Schedule code review |
this should happen after initial handover and before release |
minutes |
() |
Build |
Begin work in dev |
days |
() |
Developer tests |
Ensure all pushed to and unit tested in test |
hours |
() |
Push to Test |
Hand over initial requirements list for functional & QA validation |
minutes |
() |
Testing |
UAT & product testing (testing instance) |
days |
() |
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 |
() |
Code Freeze |
Identify changes & updates that have passed both testing regimes. Push to preproduction. |
hours |
() |
Regression Testing |
QA group conducts regression testing in preproduction |
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 |
() |
Clone |
clone from prd to: pre, trn, and tst for after release |
hours |
() |
Push to Test |
re-push outstanding, ready work back to test |
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 |