Mozillians/Releases/Process: Difference between revisions

no edit summary
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/en-US/ development server] and any commits with the appropriate commit message are changed in bugzilla to "RESOLVED/FIXED".
* 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, bugs that are "RESOLVED/VERIFIED" are pushed to production.
* 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.
Confirmed users
56

edits