Release Plan

• Each week should produce one stable & tested release candidate (RC)

• Each week includes testing work to validate the current release candidate

• Each week includes development work on the future release candidate

Start of Week:

1. Create a new Release Candidate

   1. Create a draft release with a tag in Github (ex: RC - 0.0.5), which will prompt new builds on bitrise for all HAs at the tagged commit.

   2. By default, we will use the most recent commit at the time of creating the RC, but the team can select an older commit if necessary.

   3. Ideally, this is done end of the day Friday so that the builds are all ready by Monday morning.

2. Create a New RC ticket in Jira in Sprint board for the Release Candidate (ex: RC - 0.0.5)

   1. include release notes of what was added, fixed, and the list of commits since the last Release Candidate.

3. QA Lead communicates RC build to testing resources

   1. The testing team tests all QA testing scenarios for each of the scoped jurisdictions.

During Week:

1. The development team commits to “develop” branch

2. QA tests during the week on RC “Staging” builds (directly from App Center, iOS and Android)

   1. (general regression/smoke + UAT if time allows)

End of Week:

1. PR to merge RC (ex: RC - 0.0.4) to Main

   1. 2 approvals from any development team member & a QA Lead (who is aware of general testing results from that week)

   2. Add PR to Jira RC ticket

Development Life-cycle

• Features (Jira: task)

• Bug fixes (Jira: bug)

• Security (separate Jira type?)

To Do:

• Sprint board info

• Jira process details