Development Process

This document outlines the development process for most projects.

Note

Not every project follows this—notably Socorro and Elmo. Check with your team lead or manager for clarification and then fork this.

Release Cycles

Teams work on 1, 2 or 3-week release cycles. Ultimately teams want a continuous development process, where code can be developed and placed in production immediately.

A Bugs Life

  • Most of our work is encapsulated in Bugzilla.
  • Bugs represent tasks (bugs or enhancements).
  • A developer lead will typically group the bugs into milestones.
    • Each milestone represent a release.
    • All work done on a project belong in that milestone.
  • A developer assigned to a bug will typically:
    • make a “bug branch” in git
    • make code changes
    • commit the code changes
    • push them to a personal GitHub repository
    • request a review (r?):
      • In bugzilla
      • in IRC
      • over email
      • via GitHub‘s pull request system
        • http://github.com/davedash/project/compare/mybugbranch let you see differences between your work and the origin‘s master
    • After a positive review (r+) code will be merged into master and pushed to origin.
    • Most projects avoid merge commits unless they are necessary.
    • The bug is marked fixed and a comment to the GitHub commit is left in the bug.
  • QA will verify all bugs that have been marked fixed.

QA

QA will verify that bugs are fixed. If you are working on a bug that does not need QA verification mark it with [qa-] in the whiteboard status.

QA will re-open a bug if they feel it’s not complete. They will file new bugs if regressions are found within the current milestone.

Deployment

Deployment varies heavily by product. A typical project will branch master into prod and tag the release with the milestone.

It will then deploy anything in prod.

A typical push consists of:

  • Branching and tagging.
  • Notifying the l10n volunteers.
  • Filing an IT request (a “push bug”).
  • Including an etherpad of special instructions if needed.
  • Upon QA and Dev approval code is pushed to production
  • QA verifies production is working properly
  • Hotfixes are made if needed
  • Or a rollback happens.

You can also check out useful documentation from IT about how we deploy websites (requires an LDAP account).

We want a “one button” push process that automates the above steps.