Skip to content
This repository was archived by the owner on Dec 12, 2018. It is now read-only.

Development Process Explained

Jump to bottom
Micah Silverman edited this page Feb 25, 2016 · 15 revisions

Background

Stormpath uses a number of the built-in features of Github as well as waffle.io to manage our development process internally. Our repo, and thus all our issues and pull requests are public. Our waffle.io page is public as well, which makes it easy to see what's in the hopper for development and who is working on what.

The rest of this page outlines the basic rules we follow to get from the backlog to done and release.

The Flow

Here's the flow of issues through the process:

backlog -> milestone -> ready -> in progress -> needs review -> done

  1. An issue gets into the backlog simply by virtue of it being defined in github.

  2. A milestone defines a unit of work to be released. All issues assigned to the milestone will be included in the release.

  3. Once a milestone is defined and issues added to it, the ready label can be applied. This indicates that these issues are ready to be worked on. Note: there should only ever be issues in the same milestone with the ready label.

  4. A developer can "pick up" an issue to work on by applying the in progress label to it. Any issue with the in progress label should also have a developer assigned to it.

  5. When an issue is ready to be reviewed, the developer who worked on it should create a Pull Request (PR) for it. The title or the description of the PR should reference the issue number with the pound sign (#) in front of it (description example: "resolves #444). The issue should have the in progress label removed and the needs review label applied.

  6. Any developer, other than the one who worked on the issue, can "pick up" the PR and become the reviewer. This is done by the reviewer assigning the PR to themselves. If there is feedback on the PR, the reviewer will assign it back to the developer for update. Once the developer has addressed the comments from the reviewer, the developer will assign the PR back to the reviewer. This continues until the reviewer approves the PR and assigns it back to the developer a final time.

  7. Once a reviewer has approved a PR and assigned it back to the developer, AND the CI build is successful, the developer will merge the PR, close the issue and delete the branch. This will automatically remove the "needs review" label. Note: If the last commit message includes one of the keywords that Github uses for automatic closure and references the issue, the issue will be closed automatically.

Waffle.io and the Flow

Working with the labels as described in the previous section, will automatically cause the issues to flow through the waffle.io columns.

Alternatively, developers can work directly in waffle.io. Dragging an issue from the Ready column to the In Progress column automatically removes the ready label and applies the in progress label to the issue in Github.

There are two things that github.com has the waffle.io does not yet:

  1. The results of the CI build (travis)
  2. The milestone view, which shows % complete

Ready

[![ready][1]][1] [1]: images/dev_process/ready.png

In Progress

[![in progress][2]][2] [2]: images/dev_process/in_progress.png

Needs Review

[![needs review][3]][3] [3]: images/dev_process/needs_review.png

Summary of The Rules

  1. All issues with the ready label applied should have a milestone assigned AND it should be the same milestone.

  2. Only issues with the current milestone should ever have the in progress label applied.

  3. Any issue with the in progress label applied should have a developer assigned.

  4. When the assigned developer completes work on an issue, that developer will:

  5. create a pull request (PR) that references the issue number in the title or description

  6. remove the in progress label from the issue

  7. apply the needs review label to the issue

  8. Another developer will assign themselves to the PR, thus becoming the reviewer.

  9. If the reviewer has comments/requests on the PR, the reviewer assigns the PR back to the `developer

  10. When the developer resolves the comments from the reviewer, the developer assigns the PR back to the reviewer

  11. repeat 1 and 2 as needed

  12. The reviewer adds a comment to the PR indicating that it is approved and assigns the PR to the developer

  13. The developer merges the PR, closes the issue and deletes the github branch/

Clone this wiki locally