Deploy demo environment from production branch

[sanason]

The Touchpoints development process as described here is too heavyweight for a project that:

• Never has more than one or two active developers
• Does not require multiple layers of sign-off before code can be pushed to production
• Does not need to support multiple versions of the software in production

The existing process has the following gates:

1. Automated tests and automated scans must pass
2. Code must be reviewed and approved
3. Behavior of new code is tested and approved in staging environment by product owner
4. Users use the product and share feedback in a demo environment
5. Finally, the owner of the system pushes the code to production

I don't think gate 4 is necessary. Day-to-day, the best place for users to test the product is in production, while using the product to accomplish the things they need to accomplish. We don't have the resources to recruit users to volunteer to test stuff in a demo environment. If, on rare occasions, we do want to beta test new features, we can do so with feature flags.

This PR eliminates the 4th gate and moves Touchpoints towards a higher-velocity trunk-based development model. It does not eliminate the demo environment, which still may have some use as a place for experimenting with Touchpoints, but it deploys the demo environment as a copy of production, rather than as a precursor to production.

Once this change is deployed to production, I intend to delete the 'main' branch.

[sanason]

I will update the description of the development process on the wiki once this is merged. For posterity's sake, here is a copy of the development process that I accuse of being too heavyweight:

How git branches are used

• Code that is releasable lives in the production branch on GitHub.
• Code that is stable lives in the main branch.
• Code that is in-development lives in the develop branch.
• Developers work in feature-branches, created off the develop branch.

How code flows from feature to develop to main to production

• LOCAL DEVELOPMENT
• feature branches are pushed to https://touchpoints-dev-name-of-dev.app.cloud.gov (each Dev has their own Dev environment)
• feature branches are submitted as Pull Requests and reviewed in GitHub
• all commits are pushed here, to this Touchpoints code repository
• upon code commit, CircleCI runs automated tests
• upon code commit, Snyk runs automated code scans
• When a feature branch is code reviewed and clicked-through on , it may be merged to develop
• When a story is completed and ready for Acceptance, a Developer pushes the develop or feature branch to the Staging environment
  • green (passing) main builds get deployed to Staging automatically via CircleCI
• ON STAGING...
• Product Owner accepts or rejects stories and/or features on the Staging environment.
• 👀 CODE REVIEW
• When stories in develop are Accepted by the Product Owner on Staging, they can be merged to main with the Team's discretion
• the develop branch is merged to main via Pull Request
  • green (passing) main builds get deployed to Demo automatically via CircleCI
• ON DEMO...
• Users can use the product and share feedback continuously ➰ in a Demo environment
• CREATING A RELEASE:
• releases are tagged using semantic versioning. for example: git tag 0.0.1
• 🚢 TO PRODUCTION!
  • green (passing) main builds can be merged to production and then deployed to Production by coordinating with [Ryan Wold](mailto:ryan.wold@gsa.gov