Story Lifetime and Deployment Process - GovWizely/webservices GitHub Wiki

This page explains how a story should be managed, from its inception to being deployed to production.

Story Lifetime

The following points describe a story's lifetime, while also giving instructions on how to manage each step.

  1. Creation: the story is created by someone. Often the person is Erik or Stuart from the ITA.

  2. Start: to start the story, give it an estimate and click "Start".

  3. Location of code: do your work on a topic branch. Be mindful to update our documentation on developerportal by opening a PR if necessary.

  4. When you feel your work is ready for review, open a PR against master assign it to a dev for review. If you want the work onto staging for feedback before it is complete, ask a dev capable of deploying to staging (James or Calum at time or writing) to do so.

  5. If you don't have further code changes to make, mark the story as "Finished". Please organize your commits at this point by squashing together etc.

  6. When the work has been deployed to staging and you don't plan on making further changes, mark the story as "Delivered" On the story, ask the requester to review the work, giving any details they'll need (URL, example search queries, etc.). Ask the requester to "Accept" the story once they're happy with the work.

  7. Once the requester is happy with the work, add the "requester review done" label to the PR. While this has been going on, you may find that the code reviewer has given the PR the "needs code changes" label and has marked the story "Started". If so, act on their feedback, making the necessary changes.

  8. At this point, if the PR hasn't been given the "code review done" label, badger the reviewer until they've reviewed the code. If both "done" labels have been given, the reviewer will merge the PR to master, causing it to be included in the next release to production.

Deploying to Staging

As much as possible, we'll use the "staging" branch to deploy to staging.

In most cases, what's on staging will be one or more open PRs. The branch for each PR will have been merged to the staging branch, and the PR will have been given the label "on staging".

If you'd like to deploy something to staging and there are already several PRs deployed, just check out the staging branch and merge what you'd like to deploy. If the PRs which are already there need rebasing, you may have to rebase everything, reset the staging branch to master then re-merge all branches that need to be staged.

Code Review

When reviewing code, in addition to making sure the changes fulfil the request of the story, please check:

  • That specs pass.
  • Test coverage: should always be kept at 100%.
  • Code Climate score: it should never decrease, unless there's a good reason.
  • That the source has been formatted by rubocop -a.

After reviewing the code, please give the PR either a "code review done" or "needs code changes" label. If the PR needs changes, mark the story as "Started" in PT.

Deploying to Production

Our policy is: if it's on master, it's good to go to production.

The release engineer (James at time of writing) will sync the govwizely and ITA repos and deploy weekly on Thursdays and on special request.