[Justice Counts] Update JC README.md with an overview of continuous d…

…eployment and database migrations for staging. (Recidiviz/recidiviz-data#29222)

## Description of the change

Add an overview in the JC README of continuous deployment.

We will also have additional documentation in go/jc-oncall that pieces
the steps together (see screenshot below). But checking in an overview
to the README would be good to do as well.

<img width="1605" alt="Screenshot 2024-04-24 at 2 37 33 PM"
src="https://github.com/Recidiviz/recidiviz-data/assets/130382407/bbf5c70b-1898-4b4a-81b0-bb029255a242">

Zenhub Ticket Recidiviz/recidiviz-data#29011

GitOrigin-RevId: 6d9a2972568e1314192e54e673b20d21d2c594e7

recidiviz/justice_counts/control_panel/README.md

@@ -210,18 +210,53 @@ If you need to update our DB schema (add a table or column, remove a column, cha
 
 1. First make the change to the schema in recidiviz/persistence/database/schema/justice_counts/schema.py.
 2. Run `pipenv run migrate-jc "name of migration"`. This will autogenerate a migration file!
-3. To run the migration against your local Postgres DB, run `pipenv run docker-jc`. During startup, it will apply the migration.
+3. [local] To run the migration against your local Postgres DB, run `pipenv run docker-jc`. During startup, it will apply the migration.
 4. If you need to undo a local migration, find the revision of the migration right before yours, and run the following command, and then delete the autogenerated file.
 
 ```
 docker exec -e SQLALCHEMY_DB_HOST=justice_counts_db -e SQLALCHEMY_DB_NAME=postgres -e SQLALCHEMY_USE_SSL=0 -e SQLALCHEMY_DB_USER=justice_counts_user -e SQLALCHEMY_DB_PASSWORD=example pulse-data-control_panel_backend-1  pipenv run alembic -c recidiviz/persistence/database/migrations/justice_counts_alembic.ini downgrade <revision>
 ```
 
-5. To run the migration against our staging or prod databases, commit your PR. It will get applied in the next deploy.
+5. [staging] To run the migration against the staging database, you will need to manually run the script below (with the dry-run flag removed) before submitting your PR. We recommend only running the migration _after_ the PR is approved and no further changes will be made to the DB schema, but _before_ submitting the PR.
 
-## Deploying
+```
+pipenv run python -m recidiviz.tools.migrations.run_migrations_to_head --dry-run --database JUSTICE_COUNTS --project-id recidiviz-staging
+```
+
+> Please note: You should only ever run migrations that are backwards compatible (i.e. safe to apply without any corresponding code changes). The database migration should always happen before the code that relies on the migration is merged. Deploying the code without first migrating the database will break our staging application.
+> The best way to ensure a safe database migration is to follow these steps:
+>
+> - Separate out the schema change PR from the corresponding code changes (put them in separate PRs).
+> - Put up the migration file for review first, merge it and run the migration.
+> - Only then should you merge the code changes that rely on that migration.
+
+6. [prod] The migration will be applied to the prod database automatically during the next prod deploy.
+
+Note: Migrations MUST be backwards compatible, otherwise staging will break in the duration between the migration and the subsequent staging deploy.
+
+## Deployment
+
+### Automatic Staging Deployment
+
+Staging deployments are automatically triggered by the Continuous Staging Deploy Github Action every Monday - Thursday night at 3am EST/12am PST.
+
+Sites for investigating deployment logs:
 
-Pre-deploy:
+- [Github Action workflow logs](https://github.com/Recidiviz/pulse-data/actions/workflows/jc_continuous_staging_deploy.yml)
+- [Cloud Build Trigger logs](https://console.cloud.google.com/cloud-build/builds;region=global?query=trigger_id%3D%2201e362f0-c3f3-40ac-b13a-c6881b3a272f%22&project=justice-counts-staging)
+
+The Github Action also raises Sentry alerts to the justice-counts project in case of failure.
+
+If for some reason a manual staging deploy is required, use the deploy_to_staging.sh
+script described in the `Deployment Scripts` section below.
+
+### Prod Deployment
+
+Prod deployment is intentially manual - to ensure that we verify our staging
+image is working as intended before deploying it to production. See the prod deployment
+script in the `Deployment Scripts` section below.
+
+### Manual Deployment Scripts
 
 1. Make sure you've run `brew install jq` (this only has to be done once)
 2. Make sure your Docker daemon is running
@@ -242,6 +277,12 @@ To determine what commits will be included in a deploy to production, run the fo
 ./recidiviz/tools/deploy/justice_counts/commits_to_be_deployed.sh -v v1.0.0
 ```
 
+To get the version number of the latest docker image that was deployed to staging, run this script:
+
+```
+./recidiviz/tools/deploy/justice_counts/version_of_latest_staging_deploy.sh
+```
+
 ### Deploy to Playtest using our Github Action
 
 1. Click on the Actions tab in Github.