From MozillaWiki
Jump to: navigation, search


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: cc: 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

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 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 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.
    • Will the hand offs be recorded in e-mails or in the bugs themselves?