##How deploy workflow relates to QA

1. We deploy one sprint at a time. At the end of a sprint the release is pushed to Stage under a code freeze for new features/stories. All stories are QA'd Accepted stories are ready to push to Prod as is. Bugs can be fixed before the sprint is deployed to Prod. OR Bugs can be added to the next sprint if it's OK to deploy the buggy story anyway. The deploy to Prod only happens after all stories on Stage are triaged.

2. After a sprint is deployed to Prod, Stage becomes the staging ground for the next sprint.

3. Dev is an integration environment that represents the current point of work. This is usually further along than Stage or Prod.

4. Client staff may only test on Stage.

5. Team staff will conduct internal QA on Stage, and may also need to use Dev from time to time.

##How deploy works for developers

1. Devs work on the pro-theme branch.
2. At the end of the sprint a new qa branch is created "pro-sprint-X", which is deployed to Stage.
3. During QA of sprint X fixes are made to pro-sprint-X branch.
4. After QA pro-sprint-X is merged to master and to pro-theme.
5. Work on sprint X+1 can happen on pro-theme while pro-sprint-X is being QA'ed.
6. Work on sprint X+2 should happen on a feature branch that will be merged into pro-theme later.

##Deploying configuration

1. Ideally all configuration changes can happen in features or update hooks.

##Hot Fixes

1. Hot fixes for the old or new site should be tested on Stage. It may be necessary to reset Stage to a copy of Prod depending on the complexity of the fix.