Services/ProdReleasePlan: Difference between revisions
< Services
Jump to navigation
Jump to search
| (11 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
= [STALE] - moved to [[Services/Process/ServerReleaseProcess| Server Release Process]] = | |||
= Introduction = | = Introduction = | ||
| Line 6: | Line 5: | ||
= Sequence of events = | = Sequence of events = | ||
== 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]]. 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 == | |||
* 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 = | = Open Questions = | ||
These are open questions. Answers will be incorporated into this page and this section can be removed subsequently. | 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. | |||
* Anything else I've missed? | |||
** Coordination with client for features that require it | |||
** How about a push to stage first, giving us a cascaded release that we can, e.g., run CrossWeave against? | |||
Latest revision as of 15:14, 20 April 2011
[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.