Business Central CI/CD with AL-Go
How AL-Go for GitHub turns an AL extension repo into a build-test-deploy pipeline — secrets, environments, and continuous delivery.
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
.appartefacts. - An Increment Version Number workflow for bumping
app.jsonversions 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.
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.
Related guides
- Business Central web servicesThe classic OData and SOAP web services in Business Central — how they differ from the v2.0 API, and when to use them.
- Isolated storage and secrets in ALHow AL extensions store secrets safely — IsolatedStorage scopes, Azure Key Vault integration, and the patterns for managing credentials in Business Central code.
- The AL debugger in Business Central — a deep diveHow the AL debugger works for developing Business Central extensions — VS Code integration, snapshot debugging, attaching to sessions, and the productivity tricks.
- The Business Central API and OData servicesHow external systems talk to Business Central — the v2.0 REST API, OData web services, bound actions, and call limits.
- AL events and integration patternsHow AL events let extensions hook into Business Central — business events, integration events, subscriber patterns, and what to avoid.