Introduction

Alert California Release Pipelines

This repository contains Azure DevOps pipeline definitions, job templates, and helper scripts used to deploy and rollback the Alert California application.

Key files

• pipeline-release-deploy.yml — Main release pipeline (creates tags and updates release history).
• version-release-deploy.yml — Default component versions used by the release pipeline.
• pipeline-release-rollback.yml — Rollback pipeline (does not create tags or update history).
• version-release-rollback.yml — Versions file for the rollback pipeline; edit this to define the target rollback versions.
• pipeline-production-release-notes-prep.yml — Release notes generation pipeline (compares environments and generates work item summaries).
• pipeline-compare-environment-variables.yml — Utility pipeline to compare environment variables across environments.
• variables.yml — Shared variables, package names and placeholders for environment-specific values.
• jobs/ — Job templates for each component and helper jobs (validation, tagging, history update, notes generation).
• scripts/ — PowerShell scripts for environment variable retrieval, work item queries, and release notes generation.
• RELEASE-HISTORY.MD — Changelog of deployments (updated by the release pipeline).

Deployment Components

The pipeline deploys the following components:

Component	Type	Package Name
Infrastructure	SQL & Resources	alert.ca.infrastructure
Frontend API	Function App	alert.ca.frontend.api
Admin API	Web App	admin.alert.ca.imageacquisition
Camera Operation	Function App	camop.alert.ca.imageacquisition
Image Acquisition	Function App	imgacq.alert.ca.imageacquisition
Mock Camera API	Web App	mockcam.alert.ca.imageacquisition
Frontend	Container	frontend

How to use the Release Deploy pipeline

1. Prepare the manifest – Edit version-release-deploy.yml with the next major/minor/patch and the component versions you want to publish. Leave a component value empty ('') only if you need to intentionally skip it; otherwise the version must be greater than the entry listed in RELEASE-HISTORY.MD. Commit/push the change so the pipeline can read it.
2. Queue the run – Start the Deploy Release pipeline and choose the target environment (sbx, dev, uat, prd). The pipeline imports variables.yml plus the Azure DevOps variable group that matches the environment name, so make sure those values are up to date.
3. Validation stage – DebugInfo prints context, CheckVersions compares the manifest to RELEASE-HISTORY.MD, and validation-job.yml downloads only the packages flagged for deployment (and checks the container tag in ACR). If every component matches history, the stage completes and the pipeline stops without deploying.
4. Release stage – Runs only when at least one component needs an update. tag-job.yml creates the pre-deployment git tag, history-job.yml opens the pull request that updates RELEASE-HISTORY.MD, and the component jobs run in dependency order (Infrastructure → Function/Web Apps → Frontend container). Each job is gated by the deploy* flags emitted from the validation stage, so unchanged components are skipped automatically.

How to use the Release Rollback pipeline

1. Capture the target release – Update version-release-rollback.yml with the exact application and component versions you want to redeploy (copy them from the row in RELEASE-HISTORY.MD). Set a component to '' only if it should remain untouched during the rollback.
2. Queue the run – Start the Rollback Release pipeline for the desired environment. The same variable groups and variables.yml inputs are loaded as the deploy pipeline.
3. Validation stage – Downloads only the packages that have a version set and verifies the frontend container tag exists before any rollback job executes.
4. Rollback stage – Replays the component jobs with action: Rollback in the same order as the deploy pipeline. This stage redeploys the specified package versions but intentionally skips tag creation and does not modify RELEASE-HISTORY.MD.

How to use the Production Release Notes Prep pipeline

This pipeline generates release notes by comparing component versions between environments and retrieving associated work items from Azure DevOps.

1. Choose the Version Source – When queuing the pipeline, select the VersionSource parameter:

• ReleaseManifest (default) – Automatically compares the latest deployed versions in RELEASE-HISTORY.MD against target versions in version-release-deploy.yml. This is the standard mode for production release prep from this repo and requires no manual version-pair entry.
  • Optional: set CompareFromVersion (format x.x.x, for example 3.27.0) to compare from a specific release entry in RELEASE-HISTORY.MD instead of the latest one.
• Current – Compares live PRD and UAT environment variables to determine version deltas. Use this for standard releases where UAT has already been promoted and you want to document what's changing.

2. Pipeline stages:

• PrdEnvironment / UatEnvironment – Fetches environment variables from each environment and publishes them as artifacts.
• GenerateReleaseNotes – Runs the selected work items script to identify features and bugs in the version delta, then publishes release-workitems.json.
• GenerateExecutiveSummary – Uses AI to generate an executive summary from the work items.
• PublishNotes – Publishes the release notes to Notion.

3. Related scripts:

• Get-ReleaseDeltaWorkItems.ps1 – Compares PRD/UAT JSON files and retrieves work items for each component's version range.
• Get-SpecificReleaseDeltaWorkItems.ps1 – Wrapper that accepts parameterized component version pairs JSON (or optional JSON file path for local runs) and forwards those pairs to delta work item collection.
• Invoke-GenerateExecutiveNotes.ps1 – Generates AI-powered executive summary from work items.
• Publish-ReleaseNotesToNotion.ps1 – Publishes the final release notes to Notion.

Required variables for environment groups

Each environment must have an Azure DevOps variable group (named sbx, dev, uat, prd or similar) containing the following variables:

• AzureSubscription (service connection)
• ResourceGroup
• SqlServerName
• SqlDatabaseName
• FrontendAppName
• ContainerRegistry
• AdminAPIAppServiceName
• FrontendAPIAzureAppServiceName
• CameraAzureFunctionAppName
• ImageAzureFunctionAppName
• MockCameraAPIAppServiceName (optional)

Helpful scripts

All scripts support local execution and pipeline execution where applicable; see the top of each script for usage notes and examples.

• Get-HostingEnvironmentVariables.ps1 — read a variable group and return expected variables for a given environment
• Get-AllHostingEnvironmentVariables.ps1 — for debugging, collect hosting environment variables across environments
• Compare-EnvironmentVariables.ps1 — run a quick compare across dev, uat, and prd and produce a table of differences
• Get-CommitHistory.ps1 — analyze RELEASE-HISTORY.MD and fetch commit details for release note generation
• Get-LatestComponentVersions.ps1 — query Azure DevOps package feed to find the latest published component versions

TODO

1. Currently the various components have an environment variable (AppVersion) which can be queried to verify what version is currently in that environment. The exception to this is Infrastructure, which by it's nature is a sql script and DACPAC deployment.
2. The Terraform Apply is a separate pipeline, and it's possible for the infrastructure updates to be forgotten when pushing out new versions. Related to this, the Terraform repo needs versioning similar to what we have for the component repositories, in case we need to target a specific version, e.g., rollback.