Update documentation for new release process

Author: sarayourfriend

documentation/api/guides/deploy.md

@@ -4,17 +4,10 @@
 For more information on how deployments work, please see the [general deployment guide](/general/deployment.md).
 ```
 
-1. Visit
-   [https://api-staging.openverse.engineering/version](https://api-staging.openverse.engineering/version)
-   and
-   [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. [Publish the drafted API release in the GitHub release page of the monorepo](https://github.com/WordPress/openverse/releases?q=api-)
+   - Here you can preview the changes included in the API release and decide
+     whether a release is necessary and adjust monitoring during the deployment
+     accordingly.
 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).

documentation/catalog/guides/deploy.md

@@ -13,13 +13,10 @@
    unpause it back.
    ```
 
-1. Visit the
-   [Catalog Docker image](https://github.com/WordPress/openverse/pkgs/container/openverse-catalog)
-   page and copy the SHA of the image tagged `latest`.
-1. 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 the previous step
+1. [Publish the drafted catalog release in the GitHub release page of the monorepo](https://github.com/WordPress/openverse/releases?q=catalog-)
+   - Here you can preview the changes included in the catalog release and decide
+     whether a release is necessary and adjust monitoring during the deployment
+     accordingly.
 
 ## Deployment
 

documentation/frontend/guides/deploy.md

@@ -4,17 +4,10 @@
 For more information on how deployments work, please see the [general deployment guide](/general/deployment.md).
 ```
 
-1. Visit
-   [https://staging.openverse.org/version.json](https://staging.openverse.org/version.json)
-   and
-   [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.
+1. [Publish the drafted frontend release in the GitHub release page of the monorepo](https://github.com/WordPress/openverse/releases?q=frontend-)
+   - Here you can preview the changes included in the frontend release and
+     decide whether a release is necessary and adjust monitoring during the
+     deployment accordingly.
 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).

documentation/general/deployment.md

@@ -143,21 +143,18 @@ the process above. The staging deployment workflows
 
 ## Production
 
-Maintainers manually dispatch the production deployment via the
-[Release app](https://github.com/WordPress/openverse/actions/workflows/release-app.yml)
-workflow. The workflow requires the tag of an existing Docker image to tag as
-the "released" image. It generates a date-based tag for the specific application
-being released, publishes a GitHub Release (which creates a git tag), tags the
-Docker image, and then triggers the deployment workflow. The workflow also opens
-a PR to add the changelog to the
+Maintainers begin the production deployment process by publishing the drafted
+release for an application. Publishing a release automatically tags the latest
+docker image for the application and opens a PR to add the changelog to the
 [documentation site's changelog directory](https://docs.openverse.org/changelogs/index.html).
 This needs to be manually approved and merged by maintainers. The person who
 triggers the release app workflow is pinged in the PR description to help with
 the visibility of the PR.
 
-The same workflow is used to create production release images for the ingestion
-server. In that case the production deployment still needs to be handled via
-Terraform.
+For the API and frontend, publishing the release also triggers an automated
+production deployment. For the catalog and ingestion server, however,
+maintainers must manually deploy the changes to production using the Terraform
+deployment process.
 
 ## Rollbacks
 

documentation/ingestion_server/guides/deploy.md

@@ -4,13 +4,10 @@
 
 1. Check [Airflow](https://airflow.openverse.engineering/home?tags=data_refresh)
    to make sure a data refresh isn't occurring.
-1. Visit the
-   [Ingestion Server Docker image](https://github.com/WordPress/openverse/pkgs/container/openverse-ingestion_server)
-   page and copy the SHA of the image tagged `latest`.
-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 the previous step.
+1. [Publish the drafted ingestion server release in the GitHub release page of the monorepo](https://github.com/WordPress/openverse/releases?q=ingestion_server-)
+   - Here you can preview the changes included in the ingestion server release
+     and decide whether a release is necessary and adjust monitoring during the
+     deployment accordingly.
 
 ## Deployment