create reusable workflows for prod and dev deploy of primary apps

[elrayle]

Description

To support dev and prod deploys in the primary apps (i.e. service, crawler, website) and to keep code DRY, this PR moves the existing dev and prod workflows for the service repo to operations. The two workflows were merged into one deploy process. Focused steps were split into separate reusable scripts. The split is primarily to accommodate the need for some repositories to deploy to multiple Azure webapps.

Secrets required at various points in the workflows:

• Passed Secrets:

  • AZURE_WEBAPP_PUBLISH_PROFILE: publish profile for the Azure WebApp being deployed
  • AZURE_SECONDARY_WEBAPP_PUBLISH_PROFILE: publish profile for a secondary Azure WebApp if being deployed

• Org Secrets:

  • AZURE_CREDENTIALS: service principal that has access to the Azure apps
  • DEPLOY_TOKEN: token that is used to determine if the deployment is allowed
  • PRODUCTION_DEPLOYERS: name of the team that defines who can deploy to production

Workflow basic process

NOTE: See input descriptions in the workflows.

1. app's workflow uses app-build-and-deploy.yml to orchestrates the process
2. app-build-and-deploy
   a. get-version
   b. uses app-build-docker-image.yml to build the Docker image and publish it to ghcr.io
   c. uses app-deploy-to-azure.yml to deploy the primary Azure webapp
   d. uses app-deploy-to-azure.yml to deploy the secondary Azure webapp, if passed info on a second Azure webapp

2.a. get-version

• if env==dev, use version from package-lock.json + -dev_shortsha (e.g. v1.2.0-dev_1D3F567890)
• if env==prod, use version from package-lock.json (e.g. v1.2.0)
• if is_release, fail if version != release tag

2.b. build-and-push-docker-image

• if env==prod, verify user has permission to deploy using app-is-deployable.yml
• build the image
• push image to ghcr.io

2.c. & d. deploy-to-azure

• if env==prod, verify user has permission to deploy using app-is-deployable.yml
• update configs in Azure
• deploy to Azure

NOTE: User permissions are checked for both image building and deploy to Azure to ensure the user has permission to modify production. This prevents accidentally allowing a user to deploy to production in the case where the calling workflow fails to verify the user's permissions.

Corresponding app PRs

The following PRs use these workflows:

• use shared dev deploy workflow in operations service#1092
• add deploy script for crawler crawler#567

Related Work

A dev deploy workflow and a prod deploy workflow were originally created separate in the service repo to establish the patterns and process needed to perform each deploy.

• add github action to build and deploy the dev CD/service service#1021
• add GitHub action for deploy of production service service#1051

[qtomlinson]

Thank you!