ReMo Mozilla Reps/Release Process
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.
reps.mozilla.org releases go to production when significant code is ready for release. Releases may happen as often as weekly; they may be less frequent in some cases. In order for a particular change to land in a release...
- it should be described in a bug
- the bug should have a version set for a future release
- the bug should be deployed to staging by noon on the day prior to the release
Bugs that aren't deployed/deployable the day before the release will be bumped.
- A bug is filed or updated with a particular release number ("target milestone").
- A developer assigns herself the bug.
- The developer works on the bug.
- The developer issues a pull request.
- A second developer with repository administration privileges reviews the new code and, if it is satisfactory, merges it into the /mozilla/remo repository on GitHub.
- If there is a merge conflict, the requester must resolve the conflict before the code can be merged into the mozilla/remo repository.
- QA engineers may monitor code merged to the /mozilla/remo repository on GitHub.
- Within 15 minutes, the continuous integration service (Jenkins) checks out the merged code, builds it, runs any unit tests, and publishes the status of the build.
- Only if Jenkins tests pass, the code is automatically deployed on the 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.
- 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:
- 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.