Release Process

Namespaced Tags

This monorepo contains multiple independently deployable surfaces. Production releases use namespaced tags to identify which surface is being released.

Surface	Tag Pattern	Example	Workflow
Pexip SDK	pexip-sdk/v<major>.<minor>.<patch>	pexip-sdk/v1.2.3	deploy-pexip-sdk-prod.yml
Agent App	agent-app/v<major>.<minor>.<patch>	agent-app/v2.0.1	deploy-agent-app-prod.yml
Customer App	customer-app/v<major>.<minor>.<patch>	customer-app/v1.0.0	deploy-customer-app-prod.yml

Note: As of May 2026, production workflows and tagging are staged for cutover but not yet in use. Activation is pending Change Advisory Board (CAB) approval to fully transition production deployments from Azure DevOps to GitHub Actions.

Each prod workflow’s trigger filters on its own prefix - creating pexip-sdk/v1.2.3 triggers only the pexip-sdk prod deploy, not agent-app or customer-app.

How to Cut a Release

Prerequisites

1. The code is merged to main and deployed to the test environment.
2. UAT has passed on the test environment.
3. You have push access to the repository (or bypass permissions for tag protection rules).

Steps

# 1. Ensure you're on main and up to date
git checkout main && git pull

# 2. Create the namespaced tag
git tag pexip-sdk/v1.2.3

# 3. Push the tag to trigger the production workflow
git push origin pexip-sdk/v1.2.3

Replace pexip-sdk/v1.2.3 with the appropriate surface and version number.

What Happens Next

• SWA surfaces (agent-app, customer-app): The workflow deploys directly to the production Static Web App.
• Pexip SDK: The workflow deploys to the staging slot, then performs a slot swap to promote to production (see below).

Manual Dispatch Fallback

Production SWA workflows also support workflow_dispatch with a confirmation input. Navigate to the workflow in the GitHub Actions UI and type deploy when prompted:

workflow_dispatch:
  inputs:
    confirm:
      description: "Type 'deploy' to confirm manual production deployment"
      required: true

Any value other than deploy (or blank) causes the job to skip.

Pexip SDK Slot-Swap Model

The pexip-sdk production deployment uses a two-swap pattern across three Function App slots:

Slot Topology

Slot	Purpose
production	Live production traffic
staging	Receives the next candidate release (disposable - overwritten each cycle)
staging-2	Retains the previous production version for immediate rollback

Promotion Flow

Starting state: production=V, staging-2=V-1 (rollback), staging=stale

1. Deploy - V+1 is deployed to the staging slot (automated via tag trigger)
2. Swap 1 - production ↔ staging: production=V+1, staging=V
3. Swap 2 - staging ↔ staging-2: staging-2=V (becomes the new rollback)

Final state: production=V+1, staging-2=V (rollback), staging=V-1 (stale)

Rollback

To roll back production to the previous version:

az webapp deployment slot swap \
  --resource-group rg-application \
  --name fa-maxconf-prod \
  --slot staging-2 \
  --target-slot production

This immediately puts the previous version (V) back into production.

Viewing Release History

# All releases for a specific surface:
git tag -l "pexip-sdk/v*"

# All production releases across all surfaces:
git tag -l "*/v*"

Production Safeguards

Safeguard	Applies To	How It Works
Namespaced tag trigger	All prod workflows	Only fires on tags matching the exact pattern
Manual confirmation	SWA prod workflows	workflow_dispatch requires typing deploy
environment: prod gate	All prod workflows	If required reviewers are configured, the job pauses for approval
Cron on default branch only	VM scheduler	GitHub schedules only execute on main