Simplify development workflow for Touchpoints app

[sanason]

Original workflow

Documented here. The workflow required 3 long-lived Git branches and 3 gates before code made it to production (PR code review + automated tests, product owner reviews in staging environment, users review in demo environment).

This is pretty heavyweight for a product and team where:

• The team usually has a single developer and never more than 2 or 3.
• The product is an end-user application that only ever has a single version in production.
• There is no heavyweight release procedure imposed from above.
• We have no team of volunteer beta-testers from within our user base.

New workflow

New workflow is similar to GitHub Flow in terms of branching strategy. We may be a bit more deliberate in our process for deploying to production.

The new workflow is:

1. Developer works in a feature branch
2. Feature branch is submitted as a Pull Request and reviewed on GitHub
3. CircleCI runs automated tests; CodeQL runs code scans on all commits
4. Approved PRs are merged to main
5. Green main builds are automatically deployed to Staging via CircleCI
6. Periodically, the Product Owner reviews the changes on Staging. If fixes are required, go back to step 1. Otherwise, once the Product Owner is happy, main is tagged with a release tag.
7. Pushing a release tag triggers a deployment to Production via CircleCI

The main changes are:

1. Only 1 long-lived Git branch, main, which deploys automatically to the staging environment.
2. main is to be treated as always deployable. Developers should not merge anything to main that they would be uncomfortable being deployed immediately to production.
3. Only 2 gates before code goes to production - PR code review + automated tests, product owner reviews in staging environment.
4. Production releases will be triggered by the creation of release tags.

In the new workflow, there are two deployed environments:

• Production: deployed from the most recent release tag
• Staging: deployed from the head of main

Open questions

1. How should we name release tags?
2. Do we need any additional deployed environments? Maybe a pre-prod environment to deploy release tags to for testing?