Merge pull request #28 from DOI-DO/nmb/rollout-plan

v2.0 rollout plan draft

docs/operations/rollout-plan.md

@@ -0,0 +1,55 @@
+# v2.0 Rollout Plan (DRAFT, DELIBERATIVE, PRE-DECISIONAL)
+
+In late 2024, we will release a new version of the CEJST website. This
+document describes the process of getting that data and the latest version
+of the website released.
+
+The architecture of the site is better described in
+[../architecture/README.md](../architecture/README.md), but for the purpose of
+this document, we'll just mention that the data for the site is in a "backend"
+S3 bucket where the map tiles describing the districts have been generated by
+a Python-based data pipeline. That S3 bucket has a Cloudfront distribution in
+front of it and is accessible at static-data-screeningtool.geoplatform.gov.
+The frontend application uses that URL and some path configuration information
+to provide the correct data.
+
+The frontend application is a static site built by Gatsby in a Github Action
+then deployed to and served from an S3 bucket behind a Cloudfront distribution at
+screeningtool.geoplatform.gov.
+
+## Backend Data Rollout
+
+The CEJST data is stored in an S3 bucket under "versioned" paths (we think)
+using `1.0/` in the path. When we build the updated data pipeline for CEJST
+2.0, we will configure it to export the files into the existing bucket under
+paths marked `2.0/`. The hypothesis is that this will give an updated version
+of the CEJST data in that bucket without affecting the data being served by
+the existing website
+
+TODO: Validate the hypotheses that
+  - the frontend website pulls its backend data from versioned paths
+  - the data pipeline that builds the backend data can be configured
+    so that it will not overwrite any of the existing data in the same
+    bucket
+
+## Frontend app rollout
+
+Rather than trying to incrementally change the frontend app that is deployed
+at screeningtool.geoplatform.gov, we will deploy the new 2.0 version of the
+frontend website in a new S3 bucket with a new Cloudfront distribution, and
+configured to use the new backend data under the `2.0/` paths. This
+will allow us to test the deploy process, website improvements, and the
+display of the updated data using a staging URL like
+<random-string-of-letters>.cloudfront.net.
+
+TODO: Get new AWS resources
+  - A new website S3 bucket
+  - A new Cloudfront distribution that serves that S3 bucket
+
+## Release day
+
+When the 2.0 CEJST is ready to release to the public, we can change the
+screeningtool.geoplatform.gov domain name to point to the new frontend
+Cloudfront distribution instead of the one that it currently goes to. With
+this one change, after the DNS change propagates, users online will see the
+new frontend website which is configured to display the new backend data.