ALbuild
ALbuild is a complete toolchain for Microsoft Dynamics 365 Business Central AL development, build and deployment, built and maintained by 365 business development GmbH. It gives you everything you need to compile, test, sign, package, publish and deploy AL apps, on a developer machine, in Azure DevOps CI/CD and from an AI agent, without any dependency on BcContainerHelper.
ALbuild is based on the published PowerShell package
businessdev.ALbuild.
Why ALbuild
One engine, so local and CI cannot drift apart
All of the logic lives in the PowerShell module. The Azure DevOps tasks, the VS Code extension, the CLI and the MCP server are thin shells over the very same cmdlets. A build that works on your machine works in the pipeline for the same reason, not by coincidence, and a fix lands everywhere at once.
That also removes the usual class of CI-only bugs: there is no second implementation to disagree with the first.
Built for AI agents, not merely usable by them
Most toolchains can be driven by an agent if you wrap them. ALbuild is designed for it:
- The MCP server exposes the engine as typed tools, so an assistant provisions a warm container, publishes and runs tests against a live Business Central instance and reads back structured results, without inventing PowerShell one-liners. Destructive operations need approval, long ones become async jobs, and each agent can be scoped to a subset of the tools.
- The CLI answers in a stable JSON envelope with stable error codes and honest exit codes, so an agent branches on the cause rather than pattern-matching prose. Asking for help never performs an action.
albuild proberuns a single AL procedure or expression locally in about 10 ms, with no container at all. It answers "what does this actually return?", the question that otherwise costs a full publish-and-test cycle, and it is the difference between an agent that verifies its own code and one that guesses.
Why that matters
An agent's characteristic failure is confident and wrong, not obviously broken. The fastest way to prevent it is to make checking cheap. That is the thinking behind the probe, the structured output and the error codes.
Dependency resolution that actually resolves
Resolve-BcDependencies is a real backtracking constraint solver, not a download loop. It mixes NuGet v3 feeds, Azure DevOps Universal Packages and committed local .app files in one resolution, pins Microsoft first-party apps to the target build, and writes a dependencies.lock.json so a rebuild months later produces the same closure.
Fast where a Business Central pipeline actually hurts
Provisioning containers dominates the wall-clock time of a BC pipeline, so that is where the work went:
- Warm container reuse with a pooled registry instead of a fresh container per run.
- Runtime package factory (
Invoke-BcRuntimeFactory): builds runtime packages for a slice of platform versions several containers at a time, batched and incremental. - Container-less builds from the same command (
Invoke-BcCompiler) whenever a container is not actually required, selectable per run. - The probe above, for the many questions that need no runtime at all.
Honest numbers and honest failures
Code coverage is measured against a source-derived denominator, so the percentage reflects your app rather than only the lines Business Central happened to report. Errors name what the world looks like and which command fixes it, rather than only that a call failed.
Independent by design
ALbuild is inspired by, but is not a fork of, BcContainerHelper. Every line is reimplemented from scratch, organised by use case, and reusable inside and outside Azure DevOps. With Microsoft ending BcContainerHelper support inside AL-Go on 2027-10-01, not depending on it is a strategic advantage rather than a matter of taste.
Two more details that only show up under load: Invoke-ALbuildPipeline runs the same Azure DevOps YAML templates on a developer machine, and Invoke-BcBuildVersionStamp claims a build version through a git compare-and-swap push, so parallel builds cannot collide on it.
See the full, source-backed comparison with BcContainerHelper, AL-Go and ALOps.
Components
ALbuild is one engine with several interfaces. The PowerShell module contains all of the logic; everything else is a thin shell that calls into it.
| Component | What it is | Who it's for |
|---|---|---|
PowerShell module (businessdev.ALbuild) | The heart of ALbuild, organised into nine use-case modules: containers, artifacts, compile, dependency resolution, signing, testing, packaging, publishing, deployment, runtime packages, Marketplace, translations and a local pipeline runner. | Build engineers and AL developers who want a reusable command library and full scripting control. |
| Azure DevOps extension | Granular, composable pipeline tasks, each wrapping exactly one cmdlet, so a pipeline reads like the steps it performs. | Teams building CI/CD pipelines for Business Central in Azure DevOps. |
| VS Code extension | Pipelines, BC containers and artifacts right in the editor sidebar. | AL developers who want their inner-loop dev tasks without leaving VS Code. |
CLI (albuild) | A cross-platform command line for the whole toolchain: provision, resolve, build, publish and test from one stable verb surface, with --json/--ndjson output. Compiles locally and drives a remote host for the container work (the macOS flow). Also runs a single AL procedure locally, with no container at all. | Mac/Linux developers, scripts, and shell-only AI agents that want the toolchain without hand-writing PowerShell. |
| MCP server | A Model Context Protocol server exposing the engine to AI agents as typed tools: provision a warm container, publish, run tests against a live BC instance, read structured results. | AI assistants (Copilot agent mode, Claude Code, OpenClaw) doing the runtime inner loop before CI. |
One engine, one source of truth
The Azure DevOps tasks, the VS Code extension, the CLI and the MCP server all drive the same businessdev.ALbuild cmdlets, so there is no behavioural drift between your local environment, your editor, an AI agent and your build server.
Requirements
- PowerShell 5.1 or 7+: the module is dual-target.
- Container operations require Windows + Docker (Business Central images are Windows-only) and fail with a clear message elsewhere. Compilation (via Microsoft's cross-platform
aldotnet tool), feed resolution, signing, Marketplace/SaaS REST and XLIFF run on any platform with PowerShell 7.
Where to next
Start here
- New to ALbuild? Get started installs the module and walks the first build.
- Want the concepts first? Architecture & modules, the dependency resolver and project configuration (
albuild.json).
By what you are doing
- Building a CI/CD pipeline → Azure DevOps extension, or migrating from V1.
- Working on a Mac or Linux box, or scripting → CLI.
- Wiring up an AI assistant → MCP server, then probing AL for the questions that need no container.
- Scripting locally in PowerShell → the module reference.
- Shipping to AppSource, deploying on-premises, or building runtime packages → Licensing & tiers covers what those need.
Deciding whether to adopt it
- Comparison with BcContainerHelper, AL-Go and ALOps, backed by sources.
- Code coverage & test quality if you are judging the testing story.