updated documentation with staging addition

This commit is contained in:
Alysia Broddrick 2023-06-16 09:10:22 -07:00
parent 32f4916951
commit 2bd11da866
No known key found for this signature in database
GPG key ID: 03917052CD0F06B7
3 changed files with 6 additions and 5 deletions

View file

@ -42,10 +42,9 @@ Optionally, load data from fixtures as well
cf run-task getgov-ENVIRONMENT --wait --command 'python manage.py load' --name loaddata
```
For the `stable` environment, developers don't have credentials so we need to
run that command using Github Actions. Go to
For the `stable` or `staging` environments, developers don't have credentials so we need to run that command using Github Actions. Go to
<https://github.com/cisagov/getgov/actions/workflows/migrate.yaml> and select
the "Run workflow" button, making sure that `stable` is selected.
the "Run workflow" button, making sure that `stable` or `staging` depending on which envirornment you desire to update.
## Getting data for fixtures

View file

@ -36,7 +36,9 @@ Binding the database in `manifest-<ENVIRONMENT>.json` automatically inserts the
# Deploy
We have two types of environments: developer "sandboxes" and `stable`. Developers can deploy locally to their sandbox whenever they want. However, only our CD service can deploy to `stable`, and it does so when we make tagged releases of `main`. This is to ensure that we have a "golden" environment to point to, and can still test things out in a sandbox space. You should make sure all of the USWDS assets are compiled and collected before deploying to your sandbox. To deploy locally to `sandbox`:
We have three types of environments: developer "sandboxes", `staging` and `stable`. Developers can deploy locally to their sandbox whenever they want. However, only our CD service can deploy to `staging` and `stable`, and it does so when we make tagged releases of `main`. For `staging`, this is done to ensure there is a non-production level test envirornment that can be used for user testing or for testing code before it is pushed to `stable`. Whereas `stable` is used to ensure that we have a "golden" environment to point to. We can refer to `stable` as our production environment and `staging` as our pre-production (pre-prod) environment.
You should make sure all of the USWDS assets are compiled and collected before deploying to your sandbox. To deploy locally to `sandbox`:
For ease of use, you can run the `deploy.sh <sandbox name>` script in the `/src` directory to build the assets and deploy to your sandbox. Similarly, you could run `build.sh <sandbox name>` script to just compile and collect the assets without deploying.