ReMo Mozilla Reps/Release Process

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.

Schedule

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.

Sequence

• 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.
  • This entails forking the Remo GitHub repository and committing code to the fork. See the docs for more information.
  • Code should adhere to PEP8.
  • Commit messages should adhere to this guide and when possible should be prefixed with a bug number:

    [fix bug 248057] Make it go to 11

• 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.