Pipelines & Environments

CI/CD runs in Azure Pipelines — that is the source of truth for builds, gates, and deployments. This page describes intent and conventions; it does not paste pipeline YAML.

What every PR pipeline runs

#	Gate	Blocking
1	Branch + linked-work-item policy	Yes
2	Secret scan	Yes
3	Build — warnings are errors	Yes
4	Lint + format	Yes
5	Unit + integration tests, results published	Yes
6	Diff-coverage gate on the changed lines	Yes
7	Database migration-ordering check	Yes

A gate blocks because a Build Validation branch policy on main requires that pipeline. The YAML alone blocks nothing. Static analysis and AI review may comment; they never block and they are not tests.

The environment ladder

flowchart LR
  PR["PR<br/>build validation"] --> Dev["Dev<br/>auto-deploy"]
  Dev --> QA["QA<br/>auto-deploy"]
  QA --> UAT["UAT<br/>gated: manual approval"]
  UAT --> Prod["Prod<br/>gated: manual approval"]

Four environments, four names, no synonyms: dev · qa · uat · prod.

Stage	Trigger	Approval
Build validation (CI)	Every PR to main	None — must be green to merge.
Dev	Merge to main	Auto-deploy.
QA	Successful Dev deploy	Auto-deploy.
UAT	Promotion	Manual — PM (Firas Alhawasli) or CTO (Wahid Bitar).
Prod	Promotion	Manual — CTO + client sign-off.

The prod approval is the mechanism, not the decision. Whether we release at all is the two-key go/no-go — PM and QA Lead, see Decision Rights. The CTO’s environment approval comes after that call, never instead of it.

Build once, promote the artifact. One build stage produces the artifact; every environment deploys that same artifact with different variables bound at deploy time. The build that reaches Prod is byte-identical to the one QA signed off. Rebuilding per environment is a defect — it means nobody tested what shipped.

Native mobile does not use this ladder: a signed build promotes through the store’s own tracks. See Native mobile.

Database migrations

• The deploy generates an idempotent migration script from the environment’s last-applied migration, wrapped in one transaction that rolls back on error.
• dev and qa: applied automatically. uat and prod: the script is produced as a reviewable artifact and applied deliberately.
• Forward-only. Never a down-migration against a client database — fix forward with a new migration.

Rollback is redeploying the previous artifact from the same pipeline’s run history; because migrations are additive and forward-only, the old build runs against the new schema. A migration that makes this impossible is a design defect — say so in the PR, not during the incident.

Secrets never live in the repo

• Secrets and connection strings live only in Key Vault–backed variable groups. Non-secret per-environment config (URLs, feature flags) lives in the repo.
• A secret scan runs on every PR and blocks on a hit. No scan, no merge.
• Any pipeline YAML containing a password, key, or connection string is a defect, not a config choice.
• Per-environment config is bound at deploy time, never baked into the build.

Caution

If you find a secret committed to Repos — including a signing keystore, a .p12 or .mobileprovision, or a password inside a doc — treat it as exposed: rotate it, purge it from history, and tell the CTO. Do not just delete the file. Disabling the pipeline that used it does not remove it from history.

Handover of production credentials to a client is tied to final payment — see Warranty Boundary.