diff --git a/.github/ISSUE_TEMPLATE/developer-onboarding.md b/.github/ISSUE_TEMPLATE/developer-onboarding.md index 74af9ef60..92ae9e3a1 100644 --- a/.github/ISSUE_TEMPLATE/developer-onboarding.md +++ b/.github/ISSUE_TEMPLATE/developer-onboarding.md @@ -83,6 +83,6 @@ export GPG_TTY ## Setting up developer sandbox -We have two types of environments: stable, and sandbox. Stable gets deployed via tagged release every sprint, and developer sandboxes are given to get.gov developers to mess around in a production-like environment without disrupting stable. Each sandbox is namespaced and will automatically be deployed too when the appropriate branch syntax is used for that space in an open pull request. There are several things you need to setup to make the sandbox work for a developer. +We have three types of environments: stable, staging, and sandbox. Stable (production)and staging (pre-prod) get deployed via tagged release, and developer sandboxes are given to get.gov developers to mess around in a production-like environment without disrupting stable or staging. Each sandbox is namespaced and will automatically be deployed too when the appropriate branch syntax is used for that space in an open pull request. There are several things you need to setup to make the sandbox work for a developer. All automation for setting up a developer sandbox is documented in the scripts for [creating a developer sandbox](../../ops/scripts/create_dev_sandbox.sh) and [removing a developer sandbox](../../ops/scripts/destroy_dev_sandbox.sh). A Cloud.gov organization administrator will have to perform the script in order to create the sandbox. diff --git a/docs/developer/database-access.md b/docs/developer/database-access.md index 9d615c477..859ef2fd6 100644 --- a/docs/developer/database-access.md +++ b/docs/developer/database-access.md @@ -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 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 diff --git a/docs/operations/README.md b/docs/operations/README.md index 0f79e3420..ac19c98d7 100644 --- a/docs/operations/README.md +++ b/docs/operations/README.md @@ -36,7 +36,9 @@ Binding the database in `manifest-.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 ` script in the `/src` directory to build the assets and deploy to your sandbox. Similarly, you could run `build.sh ` script to just compile and collect the assets without deploying.