Skip to content

Commit

Permalink
Address PR review feedback
Browse files Browse the repository at this point in the history
  • Loading branch information
@zackkrida
zackkrida committed Jul 7, 2023
1 parent 7be24dd commit 4f10e0d
Show file tree
Hide file tree
Showing 4 changed files with 31 additions and 42 deletions.
23 changes: 9 additions & 14 deletions documentation/api/guides/deploy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,26 +4,21 @@
For more information on how deployments work, please see the [general deployment guide](/general/deployment.md).
```

1. Record and verify the commit `sha` of the production site at
1. Record and verify the commit SHA of the production site at
[https://api.openverse.engineering/v1](https://api.openverse.engineering/v1).
1. Visit
[https://api-staging.openverse.engineering/version](https://api-staging.openverse.engineering/version)
and
[the api package directory](https://github.com/wordpress/openverse/pkgs/container/openverse-api).
Verify that the commit `sha` live on the staging site is also tagged with
`latest` in the package directory.

```{figure} /_static/package_directory_example.png
---
class: with-border
---
```
[the API Docker image](https://github.com/wordpress/openverse/pkgs/container/openverse-api).
Verify that the commit SHA live on the staging site is also tagged with
`latest` in the Docker image.
![GitHub package directory screenshot](/_static/package_directory_example.png)

1. Release the app via
[GitHub workflow](https://github.com/WordPress/openverse/actions/workflows/release-app.yml).
Click the "Run workflow" button, choose "api" from the dropdown, and supply
the `sha` identified in step 1.
1. That's it. The api will be deployed. You can monitor the deployment in the
the SHA identified in step 1.
1. That's it! The API will be deployed. You can monitor the deployment in the
maintainers `#openverse-notifications` channel and in the
[infrastructure repository's workflow listing](https://github.com/WordPress/openverse-infrastructure/actions).

Expand All @@ -33,10 +28,10 @@ For more information on how deployments work, please see the [general deployment
or in the Sentry UI.
1. Visit
[https://api.openverse.engineering/v1](https://api.openverse.engineering/v1)
and verify the `sha` is the same as the value you deployed.
and verify the SHA is the same as the value you deployed.
1. Review and Approve the automatically-generated changelog pull request in the
repository.
1. In the event of errors or problems, repeat the deployment process with the
previous production `sha` identified in Step 1 of this guide.
previous production SHA identified in Step 1 of this guide.
1. If anything else goes wrong or service is disrupted, consider this a
Production Incident and notify the team.
16 changes: 7 additions & 9 deletions documentation/catalog/guides/deploy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,14 @@
## Setup

1. Check
[airflow](https://href.li/?https://airflow.openverse.engineering/home?tags=data_refresh)
[Airflow](https://href.li/?https://airflow.openverse.engineering/home?tags=data_refresh)
to make sure a data refresh isn't occurring.
1. Record and verify the latest commit `sha` of the catalog in
[the catalog package directory](https://github.com/wordpress/openverse/pkgs/container/openverse-catalog).
1. Release the app via
2. Record and verify the latest commit SHA of
[the Catalog Docker image](https://github.com/wordpress/openverse/pkgs/container/openverse-catalog).
3. Release the app via
[GitHub workflow](https://github.com/WordPress/openverse/actions/workflows/release-app.yml).
Click the "Run workflow" button, choose "catalog" from the dropdown, and
supply the `sha` identified in step 1.
supply the SHA identified in step 1.

## Deployment

Expand All @@ -21,10 +21,8 @@
command.
1. `just apply dev catalog` and verify the plan before deploying.
2. Deploy production:
1. Update the value of `data_refresh_cleared` to `true` in the
[production module declaration](https://github.com/WordPress/openverse-infrastructure/blob/main/environments/prod/ingestion-server.tf#L9).
1. `just bump prod catalog` command.
1. `just apply prod catalog` and verify the plan before deploying.
2. `just apply prod catalog` and verify the plan before deploying.

## Post-deployment steps

Expand All @@ -35,6 +33,6 @@
1. Push up a PR to the infrastructure repository with the Terraform changes you
pushed (the version bump for the relevant module).
1. In the event of errors or problems, repeat the deployment process with the
previous production `sha` identified in Step 1 of this guide.
previous production SHA identified in Step 1 of this guide.
1. If anything else goes wrong or service is disrupted, consider this a
Production Incident and notify the team.
22 changes: 8 additions & 14 deletions documentation/frontend/guides/deploy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,25 +4,19 @@
For more information on how deployments work, please see the [general deployment guide](/general/deployment.md).
```

1. Record and verify the commit `sha` of the production site at
1. Record and verify the commit SHA of the production site at
[https://openverse.org/version.json](https://openverse.org/version.json).
1. Visit
[https://staging.openverse.org/version.json](https://staging.openverse.org/version.json)
and
[the frontend package directory](https://github.com/wordpress/openverse/pkgs/container/openverse-frontend).
Verify that the commit `sha` live on the staging site is also tagged with
`latest` in the package directory.

```{figure} /_static/package_directory_example.png
---
class: with-border
---
```

[the frontend Docker image](https://github.com/wordpress/openverse/pkgs/container/openverse-frontend).
Verify that the commit SHA live on the staging site is also tagged with
`latest` in the Docker image.
![GitHub package directory screenshot](/_static/package_directory_example.png)
1. Release the app via
[GitHub workflow](https://github.com/WordPress/openverse/actions/workflows/release-app.yml).
Click the "Run workflow" button, choose "frontend" from the dropdown, and
supply the `sha` identified in step 1.
supply the SHA identified in step 1.
1. That's it. The frontend will be deployed. You can monitor the deployment in
the maintainers `#openverse-notifications` channel and in the
[infrastructure repository's workflow listing](https://github.com/WordPress/openverse-infrastructure/actions).
Expand All @@ -33,8 +27,8 @@ For more information on how deployments work, please see the [general deployment
or in the Sentry UI.
1. Visit
[https://openverse.org/version.json](https://openverse.org/version.json) and
verify the `sha` is the same as the value you deployed.
verify the SHA is the same as the value you deployed.
1. Review and Approve the automatically-generated changelog pull request in the
repository.
1. In the event of errors or problems, repeat the deployment process with the
previous production `sha` identified in Step 1 of this guide.
previous production SHA identified in Step 1 of this guide.
12 changes: 7 additions & 5 deletions documentation/ingestion_server/guides/deploy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@
1. Check
[airflow](https://href.li/?https://airflow.openverse.engineering/home?tags=data_refresh)
to make sure a data refresh isn't occurring.
1. Record and verify the latest commit `sha` of the ingestion server in
[the ingestion server package directory](https://github.com/wordpress/openverse/pkgs/container/openverse-ingestion_server).
1. Record and verify the latest commit SHA of the ingestion server in
[the ingestion server Docker image](https://github.com/wordpress/openverse/pkgs/container/openverse-ingestion_server).
1. Release the app via
[GitHub workflow](https://github.com/WordPress/openverse/actions/workflows/release-app.yml).
Click the "Run workflow" button, choose "ingestion server" from the dropdown,
and supply the `sha` identified in step 1.
and supply the SHA identified in step 1.

## Deployment

Expand All @@ -25,6 +25,7 @@
[production module declaration](https://github.com/WordPress/openverse-infrastructure/blob/main/environments/prod/ingestion-server.tf#L9).
1. `just bump prod ingestion-server` command.
1. `just apply prod ingestion-server` and verify the plan before deploying.
1. Restore the value of `data_refresh_cleared` back to `false`.

## Post-deployment steps

Expand All @@ -33,8 +34,9 @@
1. Review and Approve the automatically-generated changelog pull request in the
repository.
1. Push up a PR to the infrastructure repository with the Terraform changes you
pushed (the version bump for the relevant module).
pushed (the version bump for the relevant module). Be sure to restore the
value of `data_refresh_cleared` back to `false`.
1. In the event of errors or problems, repeat the deployment process with the
previous production `sha` identified in Step 1 of this guide.
previous production SHA identified in Step 1 of this guide.
1. If anything else goes wrong or service is disrupted, consider this a
Production Incident and notify the team.

0 comments on commit 4f10e0d

Please sign in to comment.