2013-04-19 Release

Submit change request

Open a build/test change request in https://yale.service-now.com/, assign to INF SN App Support

minutes

()

Schedule code review (Mon 1pm)

this should happen after initial handover and before release

minutes

()

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 (tst).

hours

()

Final code freeze

Hand over final requirements list for functional & QA validation, w/ regression, in (tst)

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

()

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

2013/04/10 - 3

START DEFECT 3: Pager add new, use case for group pager. The quantity feature should only accept positive integers.
This was not explicit in the requirements, but we should intuitively know this. The form does not accept letters. But it previously accepted negative numbers, as well as floating point numbers. Fixing this.

2013/04/10 - 2

START DEFECT 2: Catalog items for pager should not have quantity as part of the submit / cart widget.
This was in the requirements, and left out. Fixing.

2013/04/10 - 1

START DEFECT 1: Catalog items for pager should have shopping cart.
This was in the requirements, and left out. Fixing.

2013/04/09 - 2

Defect 453: Closed Incidents showing up in the Incidents -> Open query in the Incident module in the left hand menu. This query should not show Closed or Resolved Incidents.

2013/04/08 - 1

CMDB: provide a data source, import, transform and schedule for the business service and provider service data. See

2013/04/09 - 1

START requirement 69: Enhancement Description: PTAEO prevent submission if invalid
This is just a quick fix to an out-of-order deployment situation. Making a fix to one script which was breaking PTAEO submission.
This affects three variable sets:
PTAEO initial, PTAEO recurring, PTAEO initial and recurring

2013/04/05 - 2

FRU0013928 - START Requirement 67: New catalog item Pager: Change existing
Create a new Service Catalog Item per the following parameters:
Title: Pager: Change existing
Visible to: anyone
Description: This service request allows you to change properties on an existing pager

2013/03/20 - 2

FRU0013927 - START Requirement 66: New catalog item Pager: Add New
Create a new Service Catalog Item per the following parameters:
Title: Pager: Add New
Visible to: anyone
Description: This service request allows you to request a pager on behalf of yourself or others

2013/04/05 - 1

FRU0014122 - START Requirement 74: Modify PTAEO backend for sending SYSDATE to SOAP service
Enhancement Description: Modify PTAEO backend for sending SYSDATE to SOAP service
When I initially coded the backend connection to SOAP service, I hardcoded a date in the proper format. That was good enough for a proof of concept, but we need to make this be a real date, set to current date, formatted in the proper format as accepted by the SOAP service.

2013/04/03 - 1

FRU0013930 - START requirement 69: Enhancement Description: PTAEO prevent submission if inval
Enhancement Description: PTAEO prevent submission if invalid
Right now the only protection preventing submission on bad PTAEOs is if they were never entered at all.
We need a shadow variable and an onSubmit script or some combination of technology which detects whether the PTAEO is valid or invalid during the submit. If invalid, it should prevent the submit and force the user to correct the bad PTAEO before the submit can succeed.
This affects three variable sets:
PTAEO initial, PTAEO recurring, PTAEO initial and recurring