Confirmed users
56
edits
No edit summary |
|||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
<big> | |||
== This page is deprecated. == | |||
</big> | |||
=== Purpose === | === Purpose === | ||
The purpose of this release process is to ensure that only high-quality code moves into production and does so in an orderly, predictable way that all stakeholders can depend on and plan around. | The purpose of this release process is to ensure that only high-quality code moves into production and does so in an orderly, predictable way that all stakeholders can depend on and plan around. | ||
Line 11: | Line 15: | ||
=== Sequence === | === Sequence === | ||
* A bug is filed with a particular release date. | * A bug is filed or updated with a particular release date ("target milestone"). | ||
* A developer assigns herself the bug. | * A developer assigns herself the bug. | ||
* The developer works on the bug. | * The developer works on the bug. | ||
Line 19: | Line 23: | ||
* The developer issues a pull request. | * The developer issues a pull request. | ||
* A second developer with repository administration privileges reviews the new code and, if it is satisfactory, [[Web_Testing/Automation/CodeReviewProcess#How_to_do_a_merge.3F | merges]] it into the /mozilla/mozillians repository on GitHub. | * A second developer with repository administration privileges reviews the new code and, if it is satisfactory, [[Web_Testing/Automation/CodeReviewProcess#How_to_do_a_merge.3F | merges]] it into the /mozilla/mozillians repository on GitHub. | ||
** If there is a merge conflict, the requester must resolve the conflict before the code can be merged into the mozilla/mozillians repository. | |||
** QA engineers may [[Web_Testing/Automation/CodeReviewProcess | monitor code]] merged to the /mozilla/mozillians repository on GitHub. | ** QA engineers may [[Web_Testing/Automation/CodeReviewProcess | monitor code]] merged to the /mozilla/mozillians repository on GitHub. | ||
* Within 15 minutes, the continuous integration service (Jenkins) checks out the merged code, builds it, runs any unit tests, and [https://ci.mozilla.org/job/mozillians/ publishes the status of the build]. | * Within 15 minutes, the continuous integration service (Jenkins) checks out the merged code, builds it, runs any unit tests, and [https://ci.mozilla.org/job/mozillians/ publishes the status of the build]. | ||
* Only if Jenkins tests pass, the code is automatically deployed on the [https://mozillians-dev.allizom.org | * Only if Jenkins tests pass, the code is automatically deployed on the [https://mozillians-dev.allizom.org/ development server] and any commits with the appropriate commit message are changed in bugzilla to "RESOLVED/FIXED". | ||
* Prior to the release date, and in coordination with a QA engineer, a developer with the appropriate permissions pushes the release to staging. | * Prior to the release date, and in coordination with a QA engineer, a developer with the appropriate permissions pushes the release to staging. | ||
* QA engineers run automated and ad-hoc tests against staging, seeking clarification where necessary and marking bugs with the appropriate status. | * QA engineers run automated and ad-hoc tests against staging, seeking clarification where necessary and marking bugs with the appropriate status. | ||
* On the release date | * On the release date: | ||
** An engineer with production push authority tags VERIFIED code with the Bugzilla release number | |||
** That code is pushed to production | |||
* QA engineers re-verify application functionality. | * QA engineers re-verify application functionality. |