Development process

How do we take ideas through to deployed code.

Managing issues in github projects

We have two github projects for managing our issues:

• Roadmap - used to plan when epics will be worked on
• Hub development - used for all issues that the dev team works on

Process flow

Merging staging back into dev

Changes flow back down the branches as soon as is reasonable, so that dev always contains everything on staging.

When a fix is merged into staging, the developer who merged it merges staging back into dev using the automatically generated PR, once staging has passing tests. Follow the merge rules: merges from dev, staging or master keep their history, so use a merge commit rather than a squash.

Two situations call for something different:

• Several fixes in a short period. Wait and merge them back in one go.
• A merge conflict. Whoever is best placed to resolve the conflict should do the merge. For example, where a large refactor has landed on dev and someone else makes a small change on staging, the developer who did the refactor is better placed to reconcile the two.

Github status reference

Status	Set when	Set by
Ready	Issue added to sprint (sprint label added), or QA sends it back	Product
In Progress	Developer starts work and creates a feature branch from dev	Developer
Review	Developer opens a PR	Developer
Dev TBT	PR is merged into dev; release milestone added to the issue	Developer
Dev QA Passed	QA passes the issue on dev	QA
Staging TBT	The cut is taken and dev is merged into staging	QA
Staging QA Passed	QA passes the issue on staging (2nd round)	QA
Done	Feature and regression testing complete; staging merged into main	Automatic

Dependencies

If a change is made to a non-Hub repo which needs to be released at the same time as the Hub release:

1. Once the PR is merged into dev in the non-hub repo, create a cut PR for merging it into staging.
2. Add a link to that PR on the cut PR in the Hub repo (create the cut PR first if it doesn't exist yet). Add it as a tick box list so that it can be ticked when it's merged.
3. When the cut of the hub repo is taken, a release PR will be created for merging the change in the other repo into main. Add a link to that PR on the release PR in the Hub repo.