Business Central CI/CD with AL-Go

AL-Go for GitHub is Microsoft's official template for running Business Central extension builds, tests, and deployments as GitHub Actions workflows. It replaced earlier home-grown PowerShell pipelines with a maintained, supported, free toolkit. For any Business Central project bigger than a single PTE maintained by one person, AL-Go is the right starting point.

What you get

Initialising a repository from the AL-Go template installs a .AL-Go folder with workflow definitions and PowerShell scripts. Out of the box you get:

• A CI/CD workflow that runs on every pull request and main-branch push, building the AL extensions in containers, running tests, and producing signed .app artefacts.
• An Increment Version Number workflow for bumping app.json versions between releases.
• A Publish to AppSource workflow that submits new versions to Microsoft for validation.
• A Deploy to Environment workflow that publishes to one or more named Business Central environments.
• A Create release workflow that tags a Git release and uploads the build artefacts.
• A Test Current workflow that runs the full AL test suite against a fresh container.

Setup

Fork or copy the AL-Go template, drop your AL source into the standard project folder structure, set repository secrets (a Business Central app registration's tenant ID, client ID, client secret, and the encryption key for AL-Go's own settings), and the workflows run.

Environments

Each Business Central environment you want to deploy to (Dev, UAT, Prod) is configured in settings.json with a name and a secret reference. Deployments are gated by GitHub environment protection rules — approvals, branch restrictions, deployment windows.

Containers vs cloud

AL-Go can run builds either in BC Container images on GitHub-hosted runners (slow, free, simple) or on self-hosted runners (fast if you have machines available). For most projects, container builds on GitHub-hosted runners are fine.

Multi-app repos

A single repo can hold many AL apps with dependency graphs. AL-Go builds them in order, runs cross-app tests, and packages a coordinated release.

Branching strategy

AL-Go works with trunk-based development plus feature branches. Production deployments come from main; preview deployments can come from branches.

Settings that matter early

settings.json (and per-workflow overrides) control most of AL-Go's behaviour without touching workflow YAML directly. The settings worth getting right from day one:

Setting	What it controls	Why it matters early
country	Which localisation the build container uses	Wrong country produces build errors that look unrelated to the actual code
artifact	Pinned BC platform version, or current/nextminor/nextmajor	Pinning gives repeatable builds; tracking nextminor gives early warning of breaking changes
appDependencyProbingPaths	Where AL-Go finds dependency apps (including from other repos)	Multi-repo projects need this set correctly or builds fail resolving dependencies
runs-on	Which GitHub Actions runner label builds use	Self-hosted runners need this changed from the GitHub-hosted default
keyVaultName / secrets	Where AL-Go pulls the BC app registration and other credentials from	Determines whether secrets live in GitHub Secrets or Azure Key Vault

Tracking nextminor deliberately

Most production AL-Go pipelines pin artifact to a specific, tested platform version for release builds — but it's worth also running a separate, non-blocking workflow that builds and tests against nextminor (Microsoft's upcoming release) on a schedule. This surfaces a breaking platform change weeks before it reaches your customers' sandboxes, while the pinned pipeline keeps shipping against a known-good version. Treat a nextminor failure as an early warning to investigate, not as a reason to block the current release.

AppSource submission specifics

The Publish to AppSource workflow automates packaging and submission but not Microsoft's validation itself — a submission can still be rejected on content, telemetry, or technical-validation grounds that AL-Go cannot pre-check. Run the same validation checks Microsoft's pipeline runs (available as a standalone AppSource Cop ruleset) locally or in CI before triggering the real submission workflow, so a rejection is rare rather than routine.

Secrets rotation

The Azure AD app registration credentials AL-Go uses to deploy to environments are long-lived by default unless you rotate them. Treat the client secret like any production credential: set an expiry, rotate before it lapses (a lapsed secret fails every deployment workflow simultaneously, usually discovered at the worst moment), and prefer a certificate or Key Vault-backed secret over a plain GitHub Secret where the project's security posture calls for it.

The win

A breaking platform change shows up in the PR build the moment Microsoft pushes new symbols. You catch breakage at code-review time, not at customer go-live.