Is your feature request related to a problem? Please describe.
The Experience team would like to improve the UAT process for changes on the website. Currently, we have a few methods of UAT:
Take over a demo environment: force-push to demo1/demo2/demo3
Pros: Independent environment, can make changes before merging into master
Cons: Resource-locked, long wait for environment provisioning, overkill for purely front-end changes
Test on staging (YOLO): Merge changeset into master, test on staging
Pros: Already integrated into deployment process
Cons: Need to revert or merge a fast-follow changeset if any issues are found on staging (could miss deploy cutoff)
Neither option is particularly good for getting quick feedback from design or product, so we'd like to investigate the notion of "ephemeral preview environments" through routing.
Describe the solution you'd like
An ideal workflow would be:
An Experience engineer opens a pull request
Engineer adds a PREVIEW label to the pull request
This opens up a subdomain and storage bucket with the pull request number, e.g., 1234.staging.reportstream.cdc.gov for the pull request #1234
This subdomain will be mapped to a storage bucket for serving our static assets (index.html, main.js, main.css)
The backend will still be shared; API requests can still be made to the "root" staging.prime.cdc.gov/api
Engineer pushes new changes to the pull request
This will update the assets in the new bucket and optimally would post a message to the pull request saying the update is complete
Engineer removes the PREVIEW label or merges/closes the pull request
The temporary subdomain and pull request will be closed
Additional context
There are still some potential obstacles to this, but they likely won't be hard blockers on the DevOps side
Relative pathing of assets: may be an issue if we have a separate bucket for pull request-specific index.html/main.js/main.css assets
API requests from different subdomains: should be okay since we have proxying?
Okta authentication from different subdomains: can likely add a wildcard
Analytics: potential pollution from experimental events
Is your feature request related to a problem? Please describe. The Experience team would like to improve the UAT process for changes on the website. Currently, we have a few methods of UAT:
demo1/demo2/demo3Neither option is particularly good for getting quick feedback from design or product, so we'd like to investigate the notion of "ephemeral preview environments" through routing.
Describe the solution you'd like An ideal workflow would be:
PREVIEWlabel to the pull requestPREVIEWlabel or merges/closes the pull requestAdditional context