Skip to content

Development_Flow

James Seppi edited this page Jun 9, 2017 · 2 revisions

Github Branches

  • master - Represents the current "production" code. This code has been reviewed, demoed to pertinent parties, and accepted.
  • staging - Represents the latest sprint's code. This branch is deployed automatically to a testing environment to facilitate sprint demos and testing. This branch is promoted into master once it has been accepted.
  • dev - Represents the latest development code. This branch is deployed automatically to a testing environment to facilitate testing of integrated features during development. This branch is promoted into staging and tagged for the sprint at the end of the sprint, prior to demos.

All new features should be stored in a feature branch with dev as the base. Pull requests into dev must meet acceptance requirements (acceptable code coverage, documentation, etc.) as well as referencing the specific Github issues the pull request resolves.

Summarily, a new feature or change experiences the following lifecycle:

  1. Feature branch is created off of dev
  2. Development is completed on feature branch
  3. Pull Request is created to merge feature branch into dev
  4. Pull Request has sufficient coverage, documentation, and review and is merged into dev
  5. End of sprint work promotes dev into staging
  6. Staging environment is demoed to parties and accepted
  7. Post-sprint promotion of staging to master
Clone this wiki locally