Services/Process/ServerReleaseProcess: Difference between revisions
Jump to navigation
Jump to search
m (Created page with "= 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 cha...") |
Tarek.ziade (talk | contribs) |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
This is | 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 = | = Sequence of events = | ||
== Weekly == | == Weekly == | ||
* '''Tuesday''' - Features going into that week's push are determined at the [[Services/Meetings|Services Weekly Meeting]]. A drop to Test will be made by EOB Tuesday. | * '''Tuesday''' - Features going into that week's push are determined at the [[Services/Meetings|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 | * '''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. | * '''Monday''' - Production pushes will be done every Monday in the evening. The maintenance window is 3 - 5 PM PST. | ||
== Monthly == | == 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) | * 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) | ||
| Line 12: | Line 14: | ||
= Hand off from Engineering to Test Checklist = | = Hand off from Engineering to Test Checklist = | ||
* A tag with changes | * A tag with changes | ||
* A healthy Jenkins status for the project (blue and sunny) | |||
* A test plan for changes (Template of this coming soon) | * A test plan for changes (Template of this coming soon) | ||
* Security Documentation Update and Security Sign Off (If necessary) | * Security Documentation Update and Security Sign Off (If necessary) | ||
* Dev will file deploy bugs with any special instructions for service ops. | * 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 | * Dev will send e-mail to: services-qa@mozilla.com cc: services-ops@mozilla.com with the buglist, test plan link, location of staging environment and staging database | ||
* Service Ops will push to staging. | * 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 | * 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 | ||
| Line 23: | Line 26: | ||
* QA regression tests pass | * QA regression tests pass | ||
* cross environment tests pass | * cross environment tests pass | ||
* Test plan passes | * [https://wiki.mozilla.org/QA/Sync/Test_Plan#Servers Test plan] passes | ||
* Service Ops signs off on any load testing if necessary | * Service Ops signs off on any load testing if necessary (is this in stage or production environments?) | ||
* Test sends e-mail notification to services-qa@mozilla.com with results | * Test sends e-mail notification to services-qa@mozilla.com with results | ||
| Line 38: | Line 41: | ||
** Coordination with client for features that require it - Answer: jarguello will a dependency line between the two. Probably in the feature page. | ** 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. | ** 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? | |||
Latest revision as of 12:42, 9 June 2011
Introduction
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
Weekly
- 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.
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 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: services-qa@mozilla.com cc: services-ops@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 (is this in stage or production environments?)
- 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.
- Will the hand offs be recorded in e-mails or in the bugs themselves?