This repository was archived by the owner on Oct 15, 2025. It is now read-only.
Repository navigation
Development_Flow
James Seppi edited this page Jun 9, 2017
·
2 revisions
-
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 intomasteronce 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 intostagingand 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:
- Feature branch is created off of
dev - Development is completed on feature branch
- Pull Request is created to merge feature branch into
dev - Pull Request has sufficient coverage, documentation, and review and is merged into
dev - End of sprint work promotes
devintostaging - Staging environment is demoed to parties and accepted
- Post-sprint promotion of
stagingtomaster
- Design Principles
- Content Styleguide
- Design Styleguide
- Design Sprint Workflow
- Information Architecture
- User Profiles
- Branding
- Research Strategy
- Bidder User Research
- Career Development Officer User Research
- Assignment Officer User Research
- Homepage and Filter Tests