Mozillians/Releases/Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
This document is out of date 12/6/2012 and needs to be updated.
=== 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.


== IRC Stand-up Meetings ==
=== Schedule ===
* Daily, 10am PST
In 2013, Mozillians releases go to production on Thursdays. They may happen as often as weekly; they may be less frequent in some cases.  
* 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 ==
=== Sequence ===
 
* A bug is filed with a particular release date.
=== Release Trains ===
* A developer assigns herself the bug.
* Trains leave the station every week, on Wednesdays.
* The developer works on the bug.  
* One train leaves for production. This is our actual deploy.
** This entails forking the [https://github.com/mozilla/mozillians Mozillians GitHub repository] and committing code to the fork.
** It's tagged from the HEAD of the next branch, and all the code should be on stage.
** Code should adhere to [http://www.python.org/dev/peps/pep-0008/ PEP8]
** The tag is only created when QA signs off on the bugs in that milestone.
** Commits should be squashed into an atomic unit. [https://gist.github.com/2422571 Here is a handy reference] of github commands.
** Easy to do in git, see [1].
** Commit messages should adhere to [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html this guide] and should be prefixed with a string like this: <pre>[fix bug 248057] Make it go to 11</pre>
* Another train leaves master (-dev) for next (-stage). (May leave Thursday morning.)
* The developer issues a pull request.
** Only *after* the train leaves for production.
* 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.
** See [1] for git steps. Anyone should be able to do this.
** QA engineers may [[/Web_Testing/Automation/CodeReviewProcess | monitor code]] merged to the /mozilla/mozillians repository on GitHub.
** Will need a bug to deploy -stage after forking.
* Within 15 minutes, the continuous integration service (Jenkins) checks out the merged code, builds it, and [https://ci.mozilla.org/job/mozillians/ publishes the status].  
** This is also when we should extract and update strings and push them to Verbatim.
* 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".
 
* 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 ===
* QA engineers run automated and ad-hoc tests against staging, seeking clarification where necessary and marking bugs with the appropriate status.
* New target milestones are date-based.
* On the release date, bugs that are "RESOLVED/VERIFIED" are pushed to production.
* Use them instead of whiteboard.
* QA engineers re-verify application functionality.
* Devs should be working on bugs 1-2 weeks in the future.
* QA should be verifying bugs 0-1 weeks in the future.
* 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.
* Bugs should be added or removed to the milestone based on a process we'll work out with product.
** "Triage," and the roadmap, are the guiding ideas here.
* 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.)
 
=== Date Formats ===
* ISO dates have a number of advantages.
* Let's use them everywhere.
* Git tags are YYYY-MM-DD, e.g. 2012-04-18.
* Target milestones match.
 
=== Bugs, Follow-Ups, Non-Bugs, [qa-] ===
* Almost all work should be tracked in bugs. When in doubt: bug. Bugs track the work we do and time we spend.
* 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.
* 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!

Revision as of 00:48, 5 February 2013

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.

Sequence

  • A bug is filed with a particular release date.
  • 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.
    • 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, and publishes the status.
  • Only if Jenkins tests pass, the code is 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, bugs that are "RESOLVED/VERIFIED" are pushed to production.
  • QA engineers re-verify application functionality.
Retrieved from "https://wiki.allizom.org/index.php?title=Mozillians/Releases/Process&oldid=512513"