diff --git a/documentation/api/guides/deploy.md b/documentation/api/guides/deploy.md index c791579ae90..8f590120f66 100644 --- a/documentation/api/guides/deploy.md +++ b/documentation/api/guides/deploy.md @@ -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). @@ -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. diff --git a/documentation/catalog/guides/deploy.md b/documentation/catalog/guides/deploy.md index 195017bb321..2fbeccedcf1 100644 --- a/documentation/catalog/guides/deploy.md +++ b/documentation/catalog/guides/deploy.md @@ -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 @@ -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 @@ -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. diff --git a/documentation/frontend/guides/deploy.md b/documentation/frontend/guides/deploy.md index e1bd28b8c25..d545e17e327 100644 --- a/documentation/frontend/guides/deploy.md +++ b/documentation/frontend/guides/deploy.md @@ -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). @@ -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. diff --git a/documentation/ingestion_server/guides/deploy.md b/documentation/ingestion_server/guides/deploy.md index b42d63f837e..5da581245ee 100644 --- a/documentation/ingestion_server/guides/deploy.md +++ b/documentation/ingestion_server/guides/deploy.md @@ -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 @@ -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 @@ -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.