[STALE] - moved to Server Release Process

Introduction

This is a proposed Services Release Process. 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

Weekly

• Tuesday - Features going into that week's push are determined at the Services Weekly Meeting. 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.

Monthly

• 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 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 services-qa@mozilla.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 services-qa@mozilla.com

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
• Test sends e-mail notification to services-qa@mozilla.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 services-qa@mozilla.com notifying that the push was a success or needs to be rolled back.

Open Questions

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.