zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-08-01 23:42:17 +02:00
Code Issues Projects Releases Packages Wiki Activity

Create new stable environment (#367)

Browse source 
update documentation for environments and setup new stable environment
This commit is contained in:
Logan McDonald 2023-01-17 13:54:30 -08:00 • committed by GitHub
parent 80f8748f39
commit 6a54bf1ff4
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
16 changed files with 88 additions and 137 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/operations/README.md
View file

@ -36,23 +36,13 @@ Binding the database in `manifest-<ENVIRONMENT>.json` automatically inserts the
# Deploy
We have two environments: `unstable` and `staging`. Developers can deploy locally to unstable whenever they want. However, only our CD service can deploy to `staging`, and it does so on every commit to `main`. This is to ensure that we have a "golden" environment to point to, and can still test things out in an unstable space. You should make sure all of the USWDS assets are compiled and collected before deploying to unstable. To deploy locally to `unstable`:
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`:
```bash
# Compile and collect the assets
docker-compose run node npx gulp compile
docker-compose run node npx gulp copyAssets
docker-compose run app ./manage.py collectstatic
# Deploy to unstable
cf target -o cisa-getgov-prototyping -s unstable
cf push getgov-unstable -f ops/manifests/manifest-unstable.yaml
cf run-task getgov-unstable --command 'python manage.py migrate' --name migrate
```
Alternatively, you could run the `deploy.sh` script in the `/src` directory to build the assets and deploy to `unstable`. Similarly, you could run `build.sh` script to just compile and collect the assets without deploying.
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.
Your sandbox space should've been setup as part of the onboarding process. If this was not the case, please have an admin follow the instructions [here](../../.github/ISSUE_TEMPLATE/developer-onboarding.md#setting-up-developer-sandbox).
## Serving static assets
We are using [WhiteNoise](http://whitenoise.evans.io/en/stable/index.html) plugin to serve our static assets on cloud.gov. This plugin is added to the `MIDDLEWARE` list in our apps `settings.py`.
Note that it’s a good idea to run `collectstatic` locally or in the docker container before pushing files up to `unstable`. This is because `collectstatic` relies on timestamps when deciding to whether to overwrite the existing assets in `/public`. Due the way files are uploaded, the compiled css in the `/assets/css` folder on `unstable` will have a slightly earlier timestamp than the files in `/public/css`, and consequently running `collectstatic` on`unstable` will not update `public/css` as you may expect. For convenience, both the `deploy.sh` and `build.sh` scripts will take care of that.
Note that it’s a good idea to run `collectstatic` locally or in the docker container before pushing files up to your sandbox. This is because `collectstatic` relies on timestamps when deciding to whether to overwrite the existing assets in `/public`. Due the way files are uploaded, the compiled css in the `/assets/css` folder on your sandbox will have a slightly earlier timestamp than the files in `/public/css`, and consequently running `collectstatic` on your sandbox will not update `public/css` as you may expect. For convenience, both the `deploy.sh` and `build.sh` scripts will take care of that.

6
docs/operations/runbooks/rotate_application_secrets.md
View file

@ -21,7 +21,7 @@ Where `credentials-<ENVIRONMENT>.json` looks like:
(Specific credentials are mentioned below.)
You can see the current environment with `cf env <APP>`, for example `cf env getgov-unstable`.
You can see the current environment with `cf env <APP>`, for example `cf env getgov-stable`.
The commands `cups` and `uups` stand for [`create user provided service`](https://docs.cloudfoundry.org/devguide/services/user-provided.html) and `update user provided service`. User provided services are the way currently recommended by Cloud.gov for deploying secrets. The user provided service is bound to the application in `manifest-<ENVIRONMENT>.json`.
@ -30,8 +30,8 @@ To rotate secrets, create a new `credentials-<ENVIRONMENT>.json` file, upload it
Example:
```bash
cf update-user-provided-service getgov-credentials -p credentials-unstable.json
cf restage getgov-unstable --strategy rolling
cf update-user-provided-service getgov-credentials -p credentials-stable.json
cf restage getgov-stable --strategy rolling
```
Non-secret environment variables can be declared in `manifest-<ENVIRONMENT>.json` directly.