SimpleReport Deployment Process

Intro

This page helps guide through the deployment process.

Merges to main

SimpleReport uses a continuous deployment (CD) deployment process

Once a PR is merged into main, the changes are deployed following the process below:

Revert to a Previous Release

Note: A bad version can be rolled back independent of the FE via the rollback API actions

1. checkout main
2. create a new branch (example: tim-best/revert-feature-A)
3. Revert to the desired commit git revert --no-commit 9999999..HEAD && git commit where 9999999 is the commit you want to revert to
   • This will revert everything from the HEAD back to the commit hash, meaning it will recreate that commit state in the working tree as if every commit after 9999999 had been walked back
4. Create a PR with your branch, wait for tests to pass, get approval and merge

Deploy with Action

This is helpful for deploying branches that you are developing to a lower environment for testing purposes.

If you are deploying to a lower environment (e.g. test, sr-dev1, pentest, etc...), please claim the environment you are using in Slack.

Navigate to the Github Actions Tab

1. Select the environment you want to deploy to from the workflows list on the left. In this case we are selecting the test environment
2. Click the "Run workflow" button
3. Select the branch you want to deploy. In this case we are deploying the latest commit on main
4. Click the green "Run workflow" button.
5. After the workflow is completed you can verify the changes are live by Checking the deployed commit hash. This is done my going to /app/static/commit.txt and /api/actuator/info
6. Visit the environment url to see your changes: https://{environment}.simplereport.gov/

Deployment Issues

Maintenance Mode

Users can be notified of deployment issues by placing SimpleReport in maintenance mode. When maintenance mode is enabled, a banner will appear at the top of each page stating that SimpleReport is currently experiencing an outage, along with a configurable supplemental message (e.g. a reason why).

To do so manually:

1. Create a MAINTENANCE MESSAGE in JSON format with an active and a message key. Example: {"active": true, "message": "SimpleReport is currently undergoing maintenance"}. Note that the active value must be a boolean, not a string.
2. cd frontend && MAINTENANCE_MESSAGE=(JSON message here) MAINTENANCE_ENV=(desired env) yarn run maintenance:start

Example:

MAINTENANCE_MESSAGE='{"active": true, "header" : "SimpleReport is currently experiencing an outage.", "message": "SimpleReport is currently experiencing service degradation"}' MAINTENANCE_ENV=dev yarn run maintenance:start

Possible values for MAINTENANCE_ENV: dev, test, pentest, training, demo, stg, prod

An easier way is to run the Maintenance Mode Action, which will automatically enable/disable maintenance mode for all environments with your desired message.

Dibs

To claim a lower environment for testing, you will need access to the Skylight Slack and access to #proj-cdc-prime-simplereport-engineering.

In the #proj-cdc-prime-simplereport-engineering channel (it doesn't have to be this channel, but it is nice to claim it here so that others can in that channel can see the actions being taken) do the following:

1. run /dibs list to see the environments that are open

• recommended to use any of the dev or test environments as pentest does not contain any data

2. To claim an environment, run /dibs on <environment> (e.g. /dibs on sr-dev1)

• you can claim it for a certain period of time by doing /dibs on <environment> for <duration> (e.g. /dibs on sr-dev1 for 1 hour)

3. To release the environment, run /dibs off <environment> (e.g. /dibs off sr-dev1)
4. For more /dibs commands, run /dibs help in Slack