Power Platform Developer ALM Lab

Power Platform with source-first ALM: a monorepo, ephemeral Dev/Test environments, trunk-based development, PR quality gates and GitHub Actions deployments.

Start here

1. Fork this repo to your personal GitHub account (top-right Fork button).

2. On your fork (https://github.com/<you>/alm-lab), click Code → Codespaces → Create codespace on main. All tools are preinstalled. The Codespace and free GitHub Actions minutes run on your account.

   ⚠️ Don't use a "one-click" badge that points at TALXIS/alm-lab — that starts the Codespace on the parent repo, where you can't push and your free minutes won't apply. Always launch from your own fork.

3. Wait for VS Code to load in the browser. Open a terminal (Ctrl+`) — you're in PowerShell.

4. Work through the Checkpoints below, starting with CP01. CP01 is the only one you truly must run first — it's the step that signs you in. After that, every checkpoint checks its own prerequisites (both .lab-state.json and this machine's live CLI sessions) before doing anything, so re-running a checkpoint that already succeeded is safe, and you can jump ahead or skip one you don't need. If a checkpoint can't find something it needs, it tells you exactly which earlier checkpoint to (re-)run. Not sure where you left off? Run .lab-scripts/lab-status.ps1 for a summary.

💡 Each checkpoint script is fully commented — open it, read what it does, then run it. You can run them step-by-step (F8 on selected lines) or all at once.

Signing in (CP01)

CP01 signs you in to everything up front: GitHub (gh), Power Platform (txc) and Azure (az). Two of these use a device code — the terminal prints a code and a URL; open it, paste the code, and approve. When prompted, allow the workflow scope for gh so later checkpoints can install GitHub Actions on your fork.

How each checkpoint works (PR flow)

Checkpoints don't push straight to main — they teach the real ALM loop. Each one:

1. Creates a branch and commits its changes.
2. Opens a Pull Request and prints the link.
3. Pauses — open the PR in your browser, review the diff and the running build check.
4. Press Enter to continue: it waits for the build check, squash-merges, and tags for rollback.

This is the slow, deliberate part — read the PR, watch the build go green, then merge. The first time a checkpoint enables GitHub Actions you may be asked to approve workflows on your fork — say yes.

Checkpoints

#	Script	Goal
01	CP01-check-machine-setup.ps1	Verify all tools are installed
02	CP02-create-repository-layout.ps1	Monorepo layout (solution, src, NuGet)
03	CP03-setup-continuous-integration.ps1	Branch protection — gated PRs into main
04	CP04-setup-runtime.ps1	Create Dev + Test Dataverse environments
05	CP05-setup-continuous-deployment.ps1	OIDC service principal + deploy workflow
06	CP06-implement-data-model.ps1	Warehouse tables and columns
07	CP07-implement-backend.ps1	Plugins + logic solution
08	CP08-implement-security.ps1	Security roles
09	CP09-implement-ui.ps1	Model-driven app, sitemap, forms, views, grid PCF, warehouse picking code app
10	CP10-deploy-and-sync.ps1	Deploy to Dev & pull changes back
11	CP11-move-configuration.ps1	Configuration data migration (CMT)
12	CP12-extend-branch-policies-build-checks.ps1	Require build check on PRs
13	CP13-automate-ui-testing.ps1	BDD UI test project + (manual) test workflow
14	CP14-implement-unit-tests.ps1	Plugin (FakeXrmEasy) + script (Jest) unit tests

Run a checkpoint:

.lab-scripts/CP01-check-machine-setup.ps1

Rollback

Every checkpoint commits, pushes, and tags its result. To roll back to an earlier checkpoint:

git reset --hard cp05
git push --force

Your variables persist in .lab-state.json (committed), so you can resume on a fresh Codespace even if your terminal crashes.

Resuming on a different machine

.lab-state.json travels with the repo, but auth sessions and CLI profiles (gh/txc/az) live on whatever machine you're on right now — they don't come along with a git clone. To pick up the lab on a fresh Codespace, VM, or after a crash:

1. Clone the repo (or open a new Codespace on your fork).
2. If you want to resume from a specific checkpoint rather than the latest commit: git checkout <tag> (e.g. git checkout cp07).
3. Run .lab-scripts/lab-status.ps1 — it reports which checkpoints are done according to .lab-state.json and git tags, and whether this machine's own gh/txc/az sessions actually match what lab-state expects (a mismatch here is the most common reason a checkpoint fails partway through instead of at the top with a clear message).
4. Re-run CP01 if lab-status.ps1 flags missing/mismatched auth, then continue with whichever checkpoint it names as next.

Developing this lab

See LOCAL-DRY-RUN.md to run the checkpoints locally, without forking to GitHub or provisioning real infrastructure.