AL-Go, test codeunits and a pipeline you can trust

There are still per-tenant extensions being built in Visual Studio Code on one developer's machine, packaged as an .app file, and uploaded through the Extension Management page. It works, until the developer leaves, the laptop dies, or Microsoft ships a release wave that the extension has never been compiled against. The fix is not exotic: a repository, a pipeline and some tests. Microsoft gives you the pipeline for free.

AL-Go for GitHub

AL-Go is Microsoft's open-source set of GitHub Actions and templates for Business Central development. You create a repository from the per-tenant extension template, put your app folder in it, and you get: a build on every commit against the current version, a nightly or on-demand build against the next major (the NextMajor schedule), test execution, versioning, release artefacts, and deployment to named environments (sandbox on merge, production on release) using an Entra app registration. It takes an afternoon to set up and it removes most of the ways an extension fails at update time.

The settings that matter in AL-Go-Settings.json: runNumberOffset and the versioning strategy so version numbers always increase; enableCodeCop, enableUICop and enablePerTenantExtensionCop (or AppSourceCop for marketplace apps) switched on so the analysers fail the build; NextMajorSchedule set; and the environments block with the customer's sandbox and production names. Secrets (the auth context for deployment) live in GitHub secrets, never in the repository.

Branching that fits a small team

main is what is in production. Feature branches, a pull request to main with the build and tests as required checks, merge deploys to the sandbox automatically, and a GitHub release (tag) deploys to production, by a person, in the agreed window. For a customer with one or two developers this is all the process you need. For more, add a develop branch and a release branch per major.

What a useful test codeunit looks like

AL tests are codeunits with Subtype = Test, run by the test runner against a database with the library apps installed. A good one:

• Tests a business rule, not a screen. "Releasing a sales order with a blocked customer raises error X." "Posting a purchase invoice with our surcharge field populated creates the expected G/L entry." Not "page opens".
• Builds its own data with the Library codeunits (LibrarySales, LibraryInventory, LibraryERM), so it does not depend on demo data or on the order tests run in.
• Uses asserterror and Assert.ExpectedError for the negative cases, which are where bugs live.
• Handles UI with [HandlerFunctions] for confirm dialogs and pages, so it runs headless.
• Is small. One rule per test procedure. When it fails, the name tells you what broke.

You do not need hundreds. Twenty tests covering the extension's actual rules, run on every commit and against the next major, will catch most of what a release wave changes.

The pipeline, end to end

1. Developer pushes a branch. AL-Go compiles the app and the test app against the current version, runs the analysers, runs the tests in a container. Red build, no merge.
2. Pull request reviewed by a second person (even on a two-person team; especially then). Merge to main.
3. Merge deploys to the customer's sandbox. Super users try it.
4. Release created with a version tag. Deploys to production in the maintenance window. Artefacts kept.
5. Every night, or at least weekly, the NextMajor build compiles and tests against the next release wave's preview. Warnings and failures land in an issue. By the time the update is scheduled there is nothing left to find.

Things that go wrong

• Tests that depend on demo data. They pass in Cronus and fail in the customer's database. Build the data in the test.
• Version numbers that go backwards because someone built locally. AL-Go owns the version; local builds are for development only.
• The deployment secret in the wrong place. In the repo, in a Teams message, on a wiki. GitHub secrets, scoped to the environment, rotated.
• Nobody looks at the NextMajor build. It fails in July, nobody notices, the October update breaks the extension. Route the failure to someone's inbox.
• The customer does not own the repository. It is in the partner's organisation, and when the relationship ends there is a negotiation. Create it in the customer's GitHub organisation and give the partner access, not the other way round.

If a customer asks us to take over an extension and there is no repository, the first week is setting this up before we change a line, because it is the only way to know what we are changing. If you are a developer or a customer with code in a zip somewhere, the AL code check includes getting it into a pipeline; and the design rules are the other half.

More from the blog

• How to log a Business Central support ticket that gets fixed first time Operations
• Continuity is king: why you want the same consultants from the first workshop to the last support call Projects
• Ten Business Central support tickets you do not need to log Operations