Mozillians/Releases/Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<big>
== This page is deprecated. ==
</big>


== IRC Stand-up Meetings ==
=== Purpose ===
* Daily, 10am PST
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.
* Answer 3 questions:
** What have you been doing (this morning/yesterday/etc)?
** What are you going to do now?
** What's blocking you?
* Includes devs, Aakash, Bram, QA, etc. Whoever's involved.
* If you have to skip it, or have nothing to add, just ignore the ping.


== Releases and Tracking ==
=== Schedule ===
In 2013, Mozillians releases go to production on Thursdays. They 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 target milestone set to the date of the release
* the bug should be deployed to staging by noon on the day prior to the release


=== Release Trains ===
Bugs that aren't deployed/deployable the day before the release will be bumped.
* Trains leave the station every week, on Wednesdays.
* One train leaves for production. This is our actual deploy.
** It's tagged from the HEAD of the next branch, and all the code should be on stage.
** The tag is only created when QA signs off on the bugs in that milestone.
** Easy to do in git, see [1].
* Another train leaves master (-dev) for next (-stage). (May leave Thursday morning.)
** Only *after* the train leaves for production.
** See [1] for git steps. Anyone should be able to do this.
** Will need a bug to deploy -stage after forking.
** This is also when we should extract and update strings and push them to Verbatim.


=== Target Milestones ===
=== Sequence ===
* New target milestones are date-based.
* A bug is filed or updated with a particular release date ("target milestone").
* Use them instead of whiteboard.
* A developer assigns herself the bug.
* Devs should be working on bugs 1-2 weeks in the future.
* The developer works on the bug.  
* QA should be verifying bugs 0-1 weeks in the future.
** This entails forking the [https://github.com/mozilla/mozillians Mozillians GitHub repository] and committing code to the fork. [http://mozillians.readthedocs.org/en/latest/contribute.html#git-workflow See the docs for more information.]
* E.G.: If it's April 20th, a Friday, and I'm a dev and need a bug to work on, I should pick a bug in the 2012-05-02 milestone, because that is between 1 and 2 weeks in the future.
** Code should adhere to [http://www.python.org/dev/peps/pep-0008/ PEP8].
* Bugs should be added or removed to the milestone based on a process we'll work out with product.
** 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>
** "Triage," and the roadmap, are the guiding ideas here.
* The developer issues a pull request.
* Once all the bugs in the "current" (i.e. 1-2 weeks ahead) milestone are done, can move on to the milestone after that. (Or spend some time doing clean-up tasks, but we should still file bugs for those and put them in the right milestone, or learning/playing with other tools, professional development stuff, etc. We've just gotta try to do what we commit to.)
* 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.
=== Date Formats ===
** QA engineers may [[Web_Testing/Automation/CodeReviewProcess | monitor code]] merged to the /mozilla/mozillians repository on GitHub.
* ISO dates have a number of advantages.
* 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].  
* Let's use them everywhere.
* 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".
* Git tags are YYYY-MM-DD, e.g. 2012-04-18.
* Prior to the release date, and in coordination with a QA engineer, a developer with the appropriate permissions pushes the release to staging.
* Target milestones match.
* 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, Follow-Ups, Non-Bugs, [qa-] ===
** An engineer with production push authority tags VERIFIED code with the Bugzilla release number
* Almost all work should be tracked in bugs. When in doubt: bug. Bugs track the work we do and time we spend.
** That code is pushed to production
* Things that are deeply non-QA-able (doc changes, jenkins script changes, some non-prod requirements changes) can be done without bugs if they're small or iterative.
* QA engineers re-verify application functionality.
* If there are changes outside the scope of the bug (e.g. the patch fixes the bug as written but there are UX improvements to be made) file a follow-up bug.
* If the bug has already been VERIFIED, especially if it's on production, file a follow-up bug.
* If the bug is being tested on stage by QA or someone else, and still needs work that's within the scope of the original bug, reopen it. That's basically the only time to reopen bugs. Unsure if it's within the scope? Ask!
* If a bug can't be tested and verified by QA (e.g. updating PyQuery, code clean-up, etc) put "[qa-]" in the whiteboard. This tells Matt et al that they don't need to verify it (or can just mark it verified and move on).
* Major library upgrades, especially JS libraries, should be regression tested by QA. Don't mark those [qa-], but instead add steps to help QA verify that everything's OK. Usually that means nothing regressed, but try to find a specific thing or things to check.
 
 
== Development ==
 
Lots of detailed information on how to work on GitHub with the Mozillians Dev team can be found [https://gist.github.com/2422571 here].
 
=== Git Commit Messages ===
* Please put the bug number in the first line. This helps a lot with short-log formats and automated tools.
* The first line should be <= 50 chars if at all possible. More will be truncated on github.
* e.g. "[Fix bug 123456] Add some_field to UserProfile."
* Yes, "[fix bug 123456]" takes up a lot of space. Terseness and clarity can be friends, though. And it helps the github robot.
* Add more detail if necessary in the rest of the message.
* Read http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html and love it so much.
 
=== Pull-reqs, Reviews, Feedback, Squashing, Merging/Merge-Button ===
* Try to make commits atomic, but complete. At least once everything is squashed.
** Tests should end up in the same commit as the code they test.
** There shouldn't be any commits on master where existing tests fail. It breaks git bisect.
** Of course sometimes there will be, it happens.
* After opening a pull req for r? don't squash or rebase until you get an r+. Just add feedback commits on top.
* After the r+, if there are feedback commits, squash and merge so it's atomic changes.
* If a pull req is r+ed with no changes, go ahead and use that merge button!
* If it needs changes, those should get made, then r+, then rebased and squashed. Then merged.
* You don't have to use the merge button, but if you don't, remember to...
** Close the bug, the github robot won't do it for you.
** Link to the pull req and commit (if not in the pull req because of squashing) in the bug.
** Close the pull req.
* Don't merge master into a feature branch. It does really weird things. Rebase instead.
 
=== Jenkins, Baconmatt/Jig ===
* There are separate Jenkins jobs for master and next now.
* The baconmatt bot is now an instance of Jig[2] (running on my server, if it goes down, ping me).
* This is for a number of reasons:
** Jig can dump info about pull reqs into the channel. (Say "pull 220" anywhere in a message.)
** Jig maps git branches to Jenkins jobs, so it only builds the correct job when we push to master or next.
** Jig has potential to add new, cool features!
** Mostly the 2nd one, though.
* Only the mozillians job participates in the CI Game. Sorry, no double-point counting!

Latest revision as of 15:37, 6 October 2016

This page is deprecated.

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

In 2013, Mozillians releases go to production on Thursdays. They 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 target milestone set to the date of the 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 date ("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/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 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 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.
Retrieved from "https://wiki.allizom.org/index.php?title=Mozillians/Releases/Process&oldid=1150467"