Firefox/Input/Release Checklist: Difference between revisions

From MozillaWiki
< Firefox‎ | Input
Jump to navigation Jump to search
mNo edit summary
Line 1: Line 1:
== Team  ==


== Team ==
*<font color="blue">Product lead: aakashd</font>  
* <font color="blue">Product lead: aakashd</font>
*<font color="brown">Dev lead: fwenzel/davedash</font>  
* <font color="brown">Dev lead: fwenzel/davedash</font>
*<font color="orange">QA lead: stephend</font>  
* <font color="orange">QA lead: stephend</font>
*<font color="green">IT lead: push bug assignee</font>
* <font color="green">IT lead: push bug assignee</font>


== Get Ready ==
== Get Ready ==
# Decision on release date and features - <Font color="blue">Product</font>/<Font color="brown">Dev Lead</font>
#* Update [[Firefox/Input]] page - <font color="blue">Product lead</font>
#* Email input@mo with proposed schedule and version number - <font color="blue">Product lead</font>
# Triage of blocking/approval requests as needed - <Font color="blue">Product</font>/<Font color="brown">Dev Lead</font>
# Update staging data from prod if necessary.
#* Until this is automated, make sure to change both instances of ''input.moz.com'' under Django admin -> Sites back to ''input.'''stage'''.moz.com''. Otherwise the mobile site won't be served.


== Get Set ==
#Decision on release date and features - <font color="blue">Product</font>/<font color="brown">Dev Lead</font>  
# Declare a string freeze - <font color="brown">Dev lead</font>
#*Update [[Firefox/Input]] page - <font color="blue">Product lead</font>  
#* Notify localizers.
#*Email input@mo with proposed schedule and version number - <font color="blue">Product lead</font>  
# File push bug in mozilla.org/Server Operations - Web Content Push - <font color="blue">Product lead</font>
#Triage of blocking/approval requests as needed - <font color="blue">Product</font>/<font color="brown">Dev Lead</font>  
#* Offer a date and time to IT - <font color="blue">Product lead</font>
#Update staging data from prod if necessary.
# Enact a code freeze - <font color="brown">Dev lead</font>
#*Until this is automated, make sure to change both instances of ''input.moz.com'' under Django admin -&gt; Sites back to ''input.'''stage'''.moz.com''. Otherwise the mobile site won't be served.
#* Email input@mo with notification
# Staging verification - <font color="orange">QA Lead</font>
#* QA performs release testing
#* When signed off, email input@mo with notification
#* Update push bug with QA sign off
# Create release notes blog post - <font color="blue">Product Lead</font>
#* Confirm release notes with Dev lead, QA lead, others as appropriate
# Determine a Go or no Go - <font color="blue">Product lead</font>
#* If '''No Go''', email input@mo with a formal "stop" notification and a second "go" notification when the process is started again
#* If '''Go''', mention on push bug and input@mo 8 hours ahead of time.  
#**Make sure an IT lead is assigned to the bug and there is a push time.
#** Tag the branch for release with the appropriate version - <font color="brown">Dev lead</font>


== Go! ==
== Get Set  ==
# Push to production at assigned time - <font color="green">IT lead</font>
 
#* Update sphinx (via Puppet)
#Declare a string freeze - <font color="brown">Dev lead</font>
#* Run [[Firefox/Input/Update_Script|/root/bin/input_update.sh]]
#*Notify localizers.
#* Update update_product_details script
#File push bug in mozilla.org/Server Operations - Web Content Push - <font color="blue">Product lead</font>
#* Run [[Firefox/Input/Crons|Crons]] mentioned by <font color="brown">Dev lead</font>
#*Offer a date and time to IT - <font color="blue">Product lead</font>
#* Clear out the cache
#Enact a code freeze - <font color="brown">Dev lead</font>
# QA verifies production changes - <font color="orange">QA Lead</font>
#*Email input@mo with notification
# Send out the blogpost - <font color="blue">Product lead</font>
#Staging verification - <font color="orange">QA Lead</font>
#*QA performs release testing
#*When signed off, email input@mo with notification
#*Update push bug with QA sign off
#Create release notes blog post - <font color="blue">Product Lead</font>
#*Confirm release notes with Dev lead, QA lead, others as appropriate
#Determine a Go or no Go - <font color="blue">Product lead</font>
#*If '''No Go''', email input@mo with a formal "stop" notification and a second "go" notification when the process is started again
#*If '''Go''', mention on push bug and input@mo 8 hours ahead of time.
#**Make sure an IT lead is assigned to the bug and there is a push time.
#**Tag the branch for release with the appropriate version - <font color="brown">Dev lead</font>
 
== Go! ==
 
#Push to production at assigned time - <font color="green">IT lead</font>  
#*Update sphinx (via Puppet)  
#*Run [[Firefox/Input/Update Script|/root/bin/input_update.sh]]  
#*Update update_product_details script  
#*Run [[Firefox/Input/Crons|Crons]] mentioned by <font color="brown">Dev lead</font>  
#*Clear out the cache  
#QA verifies production changes - <font color="orange">QA Lead</font>  
#Send out the blogpost - <font color="blue">Product lead</font>
 
== Post Mortems<font color="blue"></font> ==

Revision as of 19:08, 2 March 2011

Team

  • Product lead: aakashd
  • Dev lead: fwenzel/davedash
  • QA lead: stephend
  • IT lead: push bug assignee

Get Ready

  1. Decision on release date and features - Product/Dev Lead
    • Update Firefox/Input page - Product lead
    • Email input@mo with proposed schedule and version number - Product lead
  2. Triage of blocking/approval requests as needed - Product/Dev Lead
  3. Update staging data from prod if necessary.
    • Until this is automated, make sure to change both instances of input.moz.com under Django admin -> Sites back to input.stage.moz.com. Otherwise the mobile site won't be served.

Get Set

  1. Declare a string freeze - Dev lead
    • Notify localizers.
  2. File push bug in mozilla.org/Server Operations - Web Content Push - Product lead
    • Offer a date and time to IT - Product lead
  3. Enact a code freeze - Dev lead
    • Email input@mo with notification
  4. Staging verification - QA Lead
    • QA performs release testing
    • When signed off, email input@mo with notification
    • Update push bug with QA sign off
  5. Create release notes blog post - Product Lead
    • Confirm release notes with Dev lead, QA lead, others as appropriate
  6. Determine a Go or no Go - Product lead
    • If No Go, email input@mo with a formal "stop" notification and a second "go" notification when the process is started again
    • If Go, mention on push bug and input@mo 8 hours ahead of time.
      • Make sure an IT lead is assigned to the bug and there is a push time.
      • Tag the branch for release with the appropriate version - Dev lead

Go!

  1. Push to production at assigned time - IT lead
  2. QA verifies production changes - QA Lead
  3. Send out the blogpost - Product lead

Post Mortems