Skip to content

Developer guide

Brian Riley edited this page Feb 27, 2017 · 25 revisions

GitHub Branching Overview

The DMP Roadmap uses several branches to manage development work and ensure that the master branch always represents a stable version of the system.

  • master: the latest stable version (not necessarily a marked release ... see releases below)
  • contributions: the latest contributions from external contributors. Bug fixes and enhancements in this branch have not yet been released. This branch may or may not be stable.
  • development: the latest bug fixes and enhancements that the project team is working on. These changes have not yet been released. This branch may or may not be stable.
  • any other branches: represent development work that is likely unstable

Releases

The DMP Roadmap team operates in a semi-agile manner and participates in a bi-weekly sprint cycle when possible. You can always see what we're working on in our current sprint by following our current sprint project. The team finalizes the work at the end of the sprint and merges it into the master branch.

These soft releases have been tested and are in a stable condition. They represent a subset of updates that will be included in the next upcoming release. Each release is represented by a git tag and the specific bug fixes and enhancements addressed by the release will be outlined in the release notes.

The team reserves the right to publish releases outside of the standard quarterly release window if necessary.

Tracking Features and Development

  • Milestones are assigned to multiple issues to group work being done that is related. Correlates to a feature.
  • Issue tracker to define work at a more granular level, using labels and milestones to categorize issues. Issues are also used to report bugs and feature requests from users.
  • The project board is used to organize and prioritize current development.
    • Pending - These are the issues that we intend to work on within the current phase of development
    • In Progress - Developers have begun work on the issue
    • Code Review - Development work has been completed and the work is scheduled for a code review
  • Pull request for a feature can be tied to issues automatically with “fixes” notation
  • After work is complete, perform a tag/release.
  • Release notes need to be created for each release ** Major releases can defined by issues which are grouped via a label (ex: MVP)

Table of Contents

Clone this wiki locally