Business Central DevOps for teams that ship extensions

What goes wrong without Business Central DevOps

Many Business Central customizations still travel as an app file built on one laptop and uploaded by hand. Nobody can say which source made the version in production. Two developers overwrite each other. A hotfix made in a hurry disappears at the next deployment.

The cost shows up at update time. Microsoft releases a new version, and an extension fails to compile. Without a pipeline, there is no quick way to find the right code, fix it, test it and publish it. A pipeline turns that scramble into a routine task with a record.

Source control for Business Central DevOps

Every extension lives in a Git repository: AL files, the app manifest, translations, permission sets and tests. Changes arrive through pull requests. A second developer reads each one before it merges. So every line in production has an author, a reason and a linked work item. History is never rewritten.

We keep branching simple. A main branch reflects what is released, and short-lived branches carry each change. A release is a tag. Code analyzers such as CodeCop and the per-tenant extension rules run on every pull request. That way, style and upgrade safety do not depend on memory.

Business Central DevOps pipelines with AL-Go or Azure DevOps

AL-Go for GitHub is Microsoft's set of ready-made workflow templates for AL projects. It compiles the extension and runs tests in a container. It also signs and versions the app, and it can publish the app to an environment. For teams on Azure DevOps, we build the same steps with BcContainerHelper.

We choose based on where your code already lives. Either way, the pipeline builds on each change. It builds again against the next Business Central version on a schedule. It also stores the resulting app file as an artifact. A red build against a future version is an early warning.

Controlled release in Business Central DevOps

The pipeline publishes a built app to a sandbox first, where a key user confirms the change. Deployment to production then needs an approval in the pipeline. It uses a service identity with rights to publish extensions and nothing more. The artifact that you tested is the one that goes live.

You can schedule per-tenant extensions to install with the next update. That avoids interrupting users mid-day. Upgrade codeunits move data when a table changes. We write down the rollback path for each release, because uninstalling an extension keeps its data unless you choose otherwise. We test that path too.

A Business Central DevOps workflow your developers can run

The pipeline belongs to you. Repositories sit in your GitHub or Azure DevOps organization. Secrets sit in your vault, and the documentation sits in the repository itself. Suppose you change partner or hire a developer. Nothing has to be rebuilt from someone's machine. Access rights are yours to grant.

We work alongside in-house developers, or as the whole development team. A short contributor guide covers how to create a development container and the branch and pull request rules. It also covers how we number versions and how we cut a release. New people become productive without a long handover.

Business Central DevOps questions

Do we need DevOps for one small extension?

A light version, yes. Even a single extension benefits from a repository and an automated build, because the next Microsoft release will need it recompiled. Templates such as AL-Go make the setup quick. The effort pays back the first time something needs a fix. So we set up Business Central DevOps even for a small project.

AL-Go for GitHub or Azure DevOps: which should we use?

Both work well. Microsoft maintains AL-Go for AL projects, and it needs little scripting. Azure DevOps suits companies that already run work items and pipelines there. We follow where your code and your people are. We do not push you to switch. The right choice is the one your team will actually use.

Can the pipeline deploy straight to production?

It can publish per-tenant extensions to online environments through Microsoft's automation and admin APIs. It uses a registered service identity to do so. We always place a manual approval before production. So an automated build never reaches live users without a named person agreeing to it.

What about extensions we do not have source code for?

Those cannot be rebuilt. If a previous partner holds the source, ask for it. The code written for you is normally yours under your agreement. Without the source, you may need to rewrite the extension before a future version stops accepting it. We can help you plan that, and cost the risk in time, not guesswork.

How do containers fit in?

A Business Central container is a disposable local server that you use to compile and test. Pipelines create one and run the tests. Then they discard it. Developers can use the same image on their own machine. Or they can develop against an online sandbox when Docker is not practical.

Related developer pages

Pipelines only help if the code and the tests are sound. The pages below cover the AL language work, automated tests and the extensions that the pipeline builds and ships. Read them to see where Business Central DevOps fits. Then we can look at how you deploy today and set up a pipeline around it. For the product detail, see AL-Go for GitHub overview on Microsoft Learn.