Deployment Information

How to deploy client

SSG

We make use of static site generation (SSG) to avoid running a node.js server for the frontend. This means that we will have stale data unless we rebuild. This also means that unsupported features must not be used.

Production

Deployment to production is done through workflows:

1. Create a pull request from master to stable and merge
2. Cron scheduled deployment of the stable branch every 30 minutes or dispatch of deploy-client-production.yml`

Staging

• On pull request it is deployed via firebase-client-hosting-pull-request.yml to a preview channel (NOT one of the domains listed below)
• On merge it is automatically deployed to the staging site via firebase-client-hosting-merge.yml

How to deploy back-end

Production

You will have to dispatch deploy-server.production.yml manually.

Staging

Will automatically be deployed on merge to master through deploy-server.staging.yml

Staging

Frontend: https://uasc-ceebc.web.app/

Backend: https://wdcc-uasc-api-staging.fly.dev/

Production

Frontend: https://uasc-prod.web.app/

• Available at https://uasc.co.nz

Backend: https://wdcc-uasc-api.fly.dev/

Firebase

We have two separate firebase projects for Staging and Prod. The service account for the prod instance will not be shared. Contact any of the contributors for access to the staging service account or client sdk.

Sanity.io

There are two separate projects for sanity, which require different env variables

• Project shared by local and preview
• Project shared by staging and production

Secrets

We have a variety of secrets used for deployment.