Skip to content

Eagle Public Release Lines

Daniel Truong edited this page Oct 3, 2026 · 2 revisions

Eagle Public Release Lines

eagle-public has two release lines. develop is the release line: tags vX.Y.Z, ships to test and prod. A second line exists only for a change that cannot ship behind a flag on develop because old and new cannot coexist in one bundle — a framework swap, a rewrite, a redesign that replaces the shell. There is at most one next line at a time: react, tags v3.0.0-beta.N.

Decision rule

Anything else, including large features, goes on develop behind a config flag (/api/config supplies runtime flags, e.g. CONTENT_SEARCH) and ships dark. Only stand up a next line when the change fails that test.

Releasing on the Angular line

The Angular line has no dev deployment. Each release goes to the test site, then prod. Every workflow is a manual dispatch.

  1. Tag develop:
    gh workflow run "Create Release Tag" --repo bcgov/eagle-public --ref develop -f version=vX.Y.Z
  2. Deploy the tag to the test site:
    gh workflow run "Deploy eagle-public to Azure staging" --repo bcgov/eagle-public --ref vX.Y.Z -f version=vX.Y.Z
  3. Check the test site, then deploy the same tag to prod:
    gh workflow run "Deploy eagle-public to Azure production (LIVE SITE)" --repo bcgov/eagle-public --ref vX.Y.Z -f version=vX.Y.Z
    Rollback is the previous vX.Y.Z tag.

Using the existing channel

This is the normal path. It needs no infrastructure work.

  1. Branch from the next line, open a PR against it. pr.yaml runs lint, test, and build on any base branch.
  2. Cut a pre-release tag from the next line:
    gh workflow run "Create Release Tag" --repo bcgov/eagle-public --ref react -f version=v3.0.0-beta.N
    release.yaml checks out the dispatched ref; its version regex accepts -beta.N.
  3. Publish it:
    gh workflow run "Deploy eagle-public to Azure staging" --repo bcgov/eagle-public --ref v3.0.0-beta.N -f version=v3.0.0-beta.N -f target=next
    target=next selects GitHub environment azure-next, whose vars hold the storage account eaglenexttestvymaysch2ag and endpoint eagle-public-next-test-gtaqa6dvexc6edhg.a02.azurefd.net.
  4. Share that URL. It has no gate and no basic auth. /api on it reaches the test rproxy (eagle-test.apps.silver.devops.gov.bc.ca) through the Front Door pass-through route, so it shows test data.
  5. A prod fix meanwhile: fix on develop, tag vX.Y.Z, ship. Then re-implement the fix on the next line in its own commit, and delete its entry under "Ports pending" in the next line's TODO.md. Never fix on the next line first.
  6. Cutover: merge the next line into develop (conflicts resolve to the next line), tag vX.0.0, deploy with target=test, then prod. Rollback is the previous vX.Y.Z tag. Delete the branch. The next endpoint stays in place for the next line.

Standing up a second preview channel

Only do this if two next lines must run at once. Avoid it. The pieces, in order:

  1. In eagle-edge azure/main.bicep, add one more static-site module (namePrefix ≤ 9 lowercase letters, e.g. eaglenext) and one more sites[] entry with backend: true — without it, /api/* on that endpoint hits storage and the SPA rewrite answers index.html with HTTP 200. Gate it with a bool param set in main.test.bicepparam, the way deployNextSite is gated. Push main; Deploy edge deploys test. Read edgeEndpointHostNames and the storage account name from the deployment outputs (az deployment group list -g c4b0a8-test-rg). The endpoint hash is assigned at deploy time and cannot be composed ahead of it.
  2. Add a federated credential on the existing identity:
    az identity federated-credential create -g c4b0a8-test-rg --identity-name eagle-public-cicd-test \
      -n gh-env-<env> --issuer https://token.actions.githubusercontent.com \
      --subject repo:bcgov/eagle-public:environment:<env> --audiences api://AzureADTokenExchange
    The Bicep grants that identity uploader roles on the new storage account.
  3. Create GitHub environment <env> on bcgov/eagle-public: deployment branch policy tags v*; vars AZURE_STORAGE_ACCOUNT, AZURE_FRONTDOOR_ENDPOINT, AZURE_SUBSCRIPTION_ID; secrets AZURE_CLIENT_ID, AZURE_TENANT_ID (same values as azure-test).
  4. In deploy-azure-staging.yaml, add the option to the target input and map it in the environment: expression.
  5. First deploy: a new Front Door route serves the platform "Page not found" page (266 KB body, on every path) for up to about 30 minutes while /api/config on the same endpoint already answers. Wait for / to return 200, then rerun the deploy so the smoke test passes.

Related

Clone this wiki locally