Confirmed users
583
edits
Line 10: | Line 10: | ||
* The developer works on the bug. | * The developer works on the bug. | ||
** This entails forking the [https://github.com/mozilla/mozillians Mozillians GitHub repository] and committing code to the fork. | ** This entails forking the [https://github.com/mozilla/mozillians Mozillians GitHub repository] and committing code to the fork. | ||
** Code should adhere to [http://www.python.org/dev/peps/pep-0008/ PEP8] | ** Code should adhere to [http://www.python.org/dev/peps/pep-0008/ PEP8]. | ||
** Commits should be squashed into an atomic unit. [https://gist.github.com/2422571 Here is a handy reference] of github commands. | ** Commits should be squashed into an atomic unit. [https://gist.github.com/2422571 Here is a handy reference] of github commands. | ||
** Commit messages should adhere to [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html this guide] and when possible should be prefixed with a bug number: <pre>[fix bug 248057] Make it go to 11</pre> | ** Commit messages should adhere to [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html this guide] and when possible should be prefixed with a bug number: <pre>[fix bug 248057] Make it go to 11</pre> | ||
* 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, [[ | * 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. | ||
** QA engineers may [[ | ** 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 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/en-US/ 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, bugs that are "RESOLVED/VERIFIED" are pushed to production. | ||
* QA engineers re-verify application functionality. | * QA engineers re-verify application functionality. |