New Project Provisioning

Every new client engagement gets stood up the same way — same repo template, same pipelines, same branch policies, same environments. This page is the checklist. The actual settings live in Azure DevOps and the repo template; this is the order to apply them in.

The provisioning flow

flowchart TD
  A["Create ADO project + team"] --> B["Create repos from template"]
  B --> C["Wire pipelines from template"]
  C --> D["Apply branch policies"]
  D --> E["Create environments + approvals"]
  E --> F["Open comms channel"]
  F --> G["Grant access by role"]
  G --> H["Seed AGENTS.md + runbook stub"]
  H --> I["Ready — first sprint can start"]

The checklist

#	Step	What good looks like
1	ADO project + team	One project per client engagement. Default team created. Area/iteration paths seeded per Boards.
2	Repos	Backend (.NET), frontend (Angular + PrimeNG), mobile (Android/iOS) as needed — each stood up with the day-one files below, never an empty repo.
3	Pipelines	A PR pipeline running every blocking gate, and a CD pipeline that builds once and promotes the artifact.
4	Branch policies	main protected: build validation, ≥1 reviewer, linked work item, no direct push. Per Branching & PRs.
5	Environments + approvals	dev auto-deploys on merge to main, qa on a successful dev deploy; uat and prod require approval. Four names, no synonyms. Secrets in Key Vault–backed variable groups, never in the repo.
6	Comms channel	One client channel + internal delivery channel. PM (Firas Alhawasli) owns cadence.
7	Grant access by role	Least-privilege by role — contributors on repos, approvers on environments. Handover credentials stay internal until final payment.
8	Seed AGENTS.md + runbook stub	Commit AGENTS.md and a runbook stub into each repo. See AI Agents.

Day one, in the repo

A repo is not provisioned until these exist:

.editorconfig · .gitattributes · .gitignore · Directory.Build.props · Directory.Packages.props · global.json · azure-pipelines/pr.yml + cd.yml · a test project wired into the PR pipeline · README.md that gets a new developer running · AGENTS.md · docs/adr/README.md · docs/runbook.md

The first six are the .NET baseline; an Angular repo swaps in eslint.config.js, .prettierrc, and the budgets block. If a repo is missing one of these, it is not provisioned — that is a checklist a human or an agent can verify in a minute.

Conventions

• Never blank. A new repo starts with the day-one files above, so linting, CI, and structure are identical across clients.
• The linter is the standard. Coding rules ship as committed config enforced in CI — nothing here to configure by hand.
• ADRs, runbooks, AGENTS.md live in the repo, not the wiki. This page only describes the setup order.

Tip

Provisioning is done once per engagement and should take an afternoon, not a week. If a step needs a decision (extra environments, a maintained release/x.x), record it as an ADR in the repo.

Caution

Do not grant client access to production credentials or the deployment environment before the engagement’s payment terms are met. Handover is tied to final payment.