Deployment Workflow

To deploy to production:

Prepare the QA environment
- drop QA database
- run QA migrations
- run QA seeds (includes creating the needed accounts)
Merge "qa" into "main"
- git fetch origin
- git checkout main
- git pull origin main
- git merge qa
- resolve any conflicts
- git push origin main
Create a "Release" on Github. When this is published and not just a draft, it will create a "tag" with the version number you used in the release, removing the need to manually push a tag number. Set this as a pre-release.
Submit security scan - requested date back is at least one week before you intend to present to change management.
Submit accessibility scan if needed
Submit Change Request, setting the deployment date at least one week after presenting to change management.
Notify the TD team (Holly Prochaska) of incoming changes and the expected deployment date
Make sure the correct version of Ruby is installed on libapps

Check that migrations were run if needed.
Look at file structure in libapps and see if public files were correctly generated.

If deploy is unsuccessful, revert to latest tagged version as follows:

download most recent tags with git fetch --tags
checkout the correct tag with git checkout 1.0.2 (Assuming 1.0.2 is the tag you want to revert to)
change config/deploy/main :branch from main to 1.0.2
deploy with cap main deploy
change the cap lock in config/deploy.rb if required by prompt in the terminal (likely to 3.18.1) and re-deploy
verify successful re-deployment