Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Tree: b30151a436
Fetching contributors…

Cannot retrieve contributors at this time

104 lines (83 sloc) 2.85 KB

Development Process

This document outlines the development process for most projects. 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
        • 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 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 varies heavily by product. A typical flux 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.

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

Jump to Line
Something went wrong with that request. Please try again.