This is the Server Release Process for the Services team. In the spirit of having time based releases, the goal of this process is to have a set interval when server side changes are pushed to production. This is to drive a consistent and predictable flow of changes on the server side. We will start with a weekly push and refine the process as we go.
Sequence of events
- Tuesday - Features going into that week's push are determined at the Services Weekly Meeting. If changes need a public announcement, Services Ops will call that out in the meeting.
- Wednesday - A drop to Test will be made by EOB Tuesday.
- Friday - Test will sign off by EOB
- Monday - Production pushes will be done every Monday in the evening. The maintenance window is 3 - 5 PM PST.
- For resource planning, there will be a monthly meeting with security (other groups too perhaps) to go over the up coming month's work. (jarguello will add this link)
Hand off from Engineering to Test Checklist
- A tag with changes
- A healthy Jenkins status for the project (blue and sunny)
- A test plan for changes (Template of this coming soon)
- Security Documentation Update and Security Sign Off (If necessary)
- Dev will file deploy bugs with any special instructions for service ops.
- Dev will send e-mail to: firstname.lastname@example.org cc: email@example.com with the buglist, test plan link, location of staging environment and staging database
- Service Ops will push to staging.
- NOTE: staging environment and staging database need to be stable during testing period. Otherwise, please notify Test by sending a notification e-mail to firstname.lastname@example.org
Test Sign Off
Test will sign off on the changes when the following criteria are met:
- QA regression tests pass
- cross environment tests pass
- Test plan passes
- Service Ops signs off on any load testing if necessary (is this in stage or production environments?)
- Test sends e-mail notification to email@example.com with results
Push to Production
- The maintenance window is 3 - 5 PM PST.
- The pertinent dev, test, and service ops folks should be there
- Test will validate the changes are working in Production and will send an e-mail to firstname.lastname@example.org notifying that the push was a success or needs to be rolled back.
These are open questions. Answers will be incorporated into this page and this section can be removed subsequently.
- Anything else I've missed?
- Coordination with client for features that require it - Answer: jarguello will a dependency line between the two. Probably in the feature page.
- How about a push to stage first, giving us a cascaded release that we can, e.g., run CrossWeave against? - Answer: jarguello spoke to test and they will do this type of verification as part of their testing in staging.
- Will the hand offs be recorded in e-mails or in the bugs themselves?