QA/QMO/Planning: Difference between revisions
Jump to navigation
Jump to search
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== | |||
'''Major Releases''' (i.e. x in x.0.0) | === Definitions === | ||
* Milestone release = a release made up of any number of bugs that are part of a goal for QMO | |||
* Security release = a small and quick release made up of security bugfixes ONLY. A security release is not part of the milestone releases (no milestone number is required here) | |||
* Push = pushing the code changes from the SVN production branch to the live site. | |||
* P1 Page: Page linked to on the main navigation bar and/or one-hop away from the home page | |||
* P2 Page: Page NOT linked to on the main navigation bar and at least 2 hops away from the home page | |||
== Composition of Release == | |||
'''Major Milestone Releases''' (i.e. x in x.0.0) | |||
* Functional changes | * Functional changes | ||
* Add/Remove of pages | * Add/Remove of pages | ||
* Add/Remove snippets on P1 pages | * Add/Remove snippets on P1 pages | ||
* Bug fixes | |||
* Add/Remove snippets on P2 and lower pages | |||
'''Minor Releases''' (i.e. y in x.y.0) | '''Minor Milestone Releases''' (i.e. y in x.y.0) | ||
* Iterative features | * Iterative features | ||
* Bug fixes | * Bug fixes | ||
| Line 13: | Line 23: | ||
* Security Bug Fixes | * Security Bug Fixes | ||
== Release | == Release Checklists == | ||
=== Milestone Release Checklist === | |||
=== | ====Get Ready==== | ||
# Determine concept of next release | |||
* | ## File or triage bugs to fix associated to concept | ||
* | ## Prioritize those bugs | ||
# Talk to WebDev for scheduling of release and resources | |||
#* Create wiki for resource and tentative schedule of beta, qa and release under QMO/ | |||
# Get subversion and admin (to WordPress) access to staging for developer (with his/her e-mail) if new under a branch in http://svn.mozilla.org/projects/quality.mozilla.org/ | |||
#* Request any changes needed on other branches under the folder as necessary for the release | |||
#* example: https://bugzilla.mozilla.org/show_bug.cgi?id=560343 | |||
#* Determine if changes need to be made to .htaccess | |||
=== | ====Get Set==== | ||
# Bugs are only committed to stage | # Bugs are only committed to stage | ||
# Bugs are verified on stage before the push | # Bugs are verified on stage before the push | ||
====Go==== | |||
# Notify IT with a bug of push to production | |||
#* include date, folder/commits content that will be sent to production, if archive of previous release is necessary and where | |||
# Code from verified bugs is committed to production on (or very close) to push date | # Code from verified bugs is committed to production on (or very close) to push date | ||
# Bugs are re-verified on production after the push | # Bugs are re-verified on production after the push | ||
# Bugs that have not been committed to production are postponed to the next milestone | # Bugs that have not been committed to production are postponed to the next milestone | ||
# Promote release via blog post with new features | |||
# Run a post-mortem on release | |||
=== Security Release Checklist === | === Security Release Checklist === | ||
# Security related bugs are committed to stage | # Security related bugs are committed to stage | ||
# Security related bugs are verified on stage | # Security related bugs are verified on stage | ||
# Security related bugs are committed to production. Other bug fix code on stage will not be committed to production | # Notify IT with a bug of push to production | ||
#* include date, commit that will be sent to production | |||
# Security related bugs are committed to production. Other bug fix code on stage will not be committed to production | |||
Latest revision as of 18:57, 3 June 2010
Definitions
- Milestone release = a release made up of any number of bugs that are part of a goal for QMO
- Security release = a small and quick release made up of security bugfixes ONLY. A security release is not part of the milestone releases (no milestone number is required here)
- Push = pushing the code changes from the SVN production branch to the live site.
- P1 Page: Page linked to on the main navigation bar and/or one-hop away from the home page
- P2 Page: Page NOT linked to on the main navigation bar and at least 2 hops away from the home page
Composition of Release
Major Milestone Releases (i.e. x in x.0.0)
- Functional changes
- Add/Remove of pages
- Add/Remove snippets on P1 pages
- Bug fixes
- Add/Remove snippets on P2 and lower pages
Minor Milestone Releases (i.e. y in x.y.0)
- Iterative features
- Bug fixes
- Add/Remove snippets on P2 and lower pages
Security Releases (i.e. z in x.y.z)
- Security Bug Fixes
Release Checklists
Milestone Release Checklist
Get Ready
- Determine concept of next release
- File or triage bugs to fix associated to concept
- Prioritize those bugs
- Talk to WebDev for scheduling of release and resources
- Create wiki for resource and tentative schedule of beta, qa and release under QMO/
- Get subversion and admin (to WordPress) access to staging for developer (with his/her e-mail) if new under a branch in http://svn.mozilla.org/projects/quality.mozilla.org/
- Request any changes needed on other branches under the folder as necessary for the release
- example: https://bugzilla.mozilla.org/show_bug.cgi?id=560343
- Determine if changes need to be made to .htaccess
Get Set
- Bugs are only committed to stage
- Bugs are verified on stage before the push
Go
- Notify IT with a bug of push to production
- include date, folder/commits content that will be sent to production, if archive of previous release is necessary and where
- Code from verified bugs is committed to production on (or very close) to push date
- Bugs are re-verified on production after the push
- Bugs that have not been committed to production are postponed to the next milestone
- Promote release via blog post with new features
- Run a post-mortem on release
Security Release Checklist
- Security related bugs are committed to stage
- Security related bugs are verified on stage
- Notify IT with a bug of push to production
- include date, commit that will be sent to production
- Security related bugs are committed to production. Other bug fix code on stage will not be committed to production