CI/CD in Business Central: current context and Microsoft’s strategy
The Dynamics 365 Business Central developer community is currently debating DevOps and CI/CD more intensely than ever. Microsoft has completely reoriented its pipeline tooling strategy toward AL-Go for GitHub, has confirmed the end of support for BcContainerHelper on October 1, 2027, and has made it clear that it will no longer deliver new CI/CD tools for AL in Azure DevOps. Dynamics 365 Business Central debate hoy con más intensidad que nunca sobre DevOps y CI/CD. Microsoft ha reorientado por completo su estrategia de herramientas de pipeline hacia AL-Go for GitHub, ha confirmado el fin de soporte de BcContainerHelper para el 1 de octubre de 2027 y ha dejado claro que ya no entregará nuevas herramientas de CI/CD para AL en Azure DevOps.
This strategic shift raises a question many teams are asking right now: should every Business Central project adopt DevOps? Or are there scenarios where such a high level of automation simply isn’t worth it? Let’s break down the latest changes and their real implications.
AL-Go for GitHub: Microsoft’s bet for DevOps in Business Central
End of BcContainerHelper and transition to GitHub
Microsoft’s message is unmistakable: the company’s official investment in DevOps tools for AL is now centered on GitHub. Both platforms (Azure DevOps and GitHub) continue to support AL pipelines, but Microsoft has stated that its future commitments are directed toward AL-Go for GitHub. GitHub.
In practice, this means that no new official Microsoft tools for AL development will be released for Azure DevOps; those who wish to remain on that platform will need to build their own pipelines or rely on third‑party solutions such as ALOps.
In April 2025, Freddy Kristiansen (the project’s main contributor) opened an issue in the official navcontainerhelper repository confirming that BcContainerHelper will no longer be supported as of October 1st, 2027. In that same announcement, Microsoft explicitly recommends that partners use AL‑Go for GitHub or another managed DevOps solution instead of maintaining their own pipelines based on BcContainerHelper.
For those of us who have spent years orchestrating builds with PowerShell scripts and manually managed containers, this marks a turning point: the tool that served as the backbone of many pipelines now has an expiration date.
A relevant fact: more than 500 partners are already using AL‑Go for GitHub, according to Microsoft in the public discussion of issue 7. This is not an experimental tool.
What is AL‑Go and how it works in AL projects
AL‑Go for GitHub is a set of GitHub templates and actions designed for AL projects, including both PTEs (Per Tenant Extensions) and AppSource applications. Its goal is to make setting up continuous integration and delivery almost plug‑and‑play, without requiring prior knowledge of pipelines, Docker, or PowerShell. With this approach, Microsoft aims to ensure that “more partners adopt these practices, raising the quality of Business Central applications.
Key features of AL‑Go for GitHub
- App creation from workflows: You can generate a new app or test app through predefined workflows, or add an existing one by uploading the .app file to the “Add existing application” workflow
- Automatic CI/CD: Applications added to the repository are automatically included in the CI/CD pipeline. Test execution and reporting are handled automatically for all test apps
- Artifacts and releases: Each successful build produces artifacts that are stored for 90 days (GitHub’s default retention period). Releases are stored indefinitely, together with the source for that version.
- Deployment to environments: A customer environment can be linked to the GitHub repository for continuous or manual deployment.
- Development environments: Allows you to create local development environments based on Docker and online SaaS environments with all applications previously deployed, ready for rapid development
- Self-maintenance: The “Update AL-Go system files” workflow ensures that repositories always use the latest version of workflows and actions, preventing them from becoming outdated.
En cuanto al rendimiento de los pipelines, la discusión pública ofrece datos concretos: cada workflow tarda entre unos pocos minutos y 15 minutos, dependiendo de la configuración El escenario más lento (15 minutos) corresponde a GitHub hosted runners con contenedores, sin caché; el más rápido (pocos minutos) utiliza GitHub hosted Linux runners con compilerfolders y caché de artefactos.
This has generated debate: some developers consider that 15 minutes for a build without tests is an order of magnitude too slow, compared to the 30–70 seconds achieved with a compiler installed/cached on a local Windows agent. Microsoft has indicated that it will continue working on improving performance, precisely due to the base of more than 500 active partners.
Benefits of DevOps and CI/CD in Business Central
The article “Is DevOps a Must for Your Business Central Project?” published by DynaExperts in September 2025 systematizes what DevOps brings to the BC ecosystem. The main benefits are:
| Capability | Description |
| Continuous Integration (CI) | Automated builds, code analysis (CodeCop, AppSourceCop), and test execution on every change |
| Continuous Delivery (CD) | Automated promotion of apps between environments |
| Compliance and standards | Technical validation for AppSource and enhancement of code quality |
| Future-Proofing | Validation against Next Major versions of BC to identify breaking changes in advance |
| Collaboration | Pull requests, branching strategies, and code reviews for multi-developer teams |
Drawbacks and costs of implementing DevOps in Business Central
However, the setup and maintenance cost cannot be ignored. The same DynaExperts article identifies the following overhead factors:
- Infrastructure: Business Central pipelines rely on Windows containers, which consume significant disk and memory resources. For small projects, this can be disproportionate.
- Learning curve and ongoing maintenance: Understanding container updates, pipeline failures, and upcoming changes (such as the planned deprecation of BcContainerHelper in AL-Go by 2027) requires continuous investment.
- Impact on delivery speed: In small single-developer projects, DevOps processes can slow down delivery, making the solution appear less agile to the client.
- Real costs: Although licensing is modest—Azure DevOps Basic is free for up to 5 users and GitHub Actions offers free tiers—the real cost is time, time that could be spent generating direct value.
When to use DevOps in Business Central depending on the type of project
The key is not “DevOps: yes or no,” but rather sizing it appropriately according to the project. The following table summarizes the criteria:
| Scenario | Full DevOps? Justification |
|---|---|
| App ISV / AppSource | Yes, essential. Automated validation, packaging, and submission to AppSource are almost mandatory. |
| Multi-developer project | Yes. Version control, pull requests, and automated testing help prevent code conflicts. |
| Long-lived or regulated solution | Yes. It ensures traceability, audit compliance, and smooth updates. |
| Multiple clients / tenants | Yes. Pipelines ensure consistency across environments. |
| One-off customization for a single tenant | Probably not. The overhead may outweigh the benefits. |
| Single developer, limited scope | Case-by-case evaluation. The investment may not be justified if the lifecycle is short. |
| Proof of concept or temporary improvement | No. Prioritize speed and cost over a formal process. |
In cases where full DevOps is excessive, the overhead of maintaining a full CI/CD pipeline may outweigh its benefits.
Tailored DevOps: a practical approach for Business Central
For small or single-developer projects, DynaExperts proposes what it calls “Right-Sized DevOps”: a set of minimal but disciplined practices that provide structure without the burden of full automation:
- Git with pull requests (even if self-reviewed): your future self will appreciate having a clear history of changes.
- Local static analysis with CodeCop to maintain code discipline. A single CI workflow for build validation: ensures that what is in the repository actually compiles.
- Manual deployments, but always using the artifacts generated by CI, ensuring that what is tested is identical to what is deployed.
- Semantic versioning and documented release notes, however simple they may be.
This approach ensures traceability and quality without slowing down delivery. If the project grows, the pipeline can always be expanded incrementally.
Trends: AI, Copilot, and the evolution of development in Business Central
The pressure on code quality and compatibility continues to increase. Several factors within the ecosystem reinforce the need for solid DevOps practices:
Mass removal of obsolete objects in version 26
Microsoft has announced that, starting with Business Central version 26, approximately 150 tables and more than 1,000 fields marked as deprecated will be removed. This impacts legacy financial management tables, obsolete fields in inventory and production, and deprecated functions within the base code itself.
For developers, the implication is direct: any custom extension that depends on these elements must be adapted, and a pipeline that compiles against the Next Major version would detect these breaking changes in advance. Additionally, direct migration from versions prior to 14 has been discontinued, requiring staged, multi-phase upgrades.
New development capabilities in the 2025 Wave 2 release
The platform continues to evolve with new features that impact the developer’s daily workflow: the ability to cancel compilation and publishing from Visual Studio Code (available since October 2025), a new AL method for truncating table data, visibility of SQL call information in performance profiles, and improvements to the page scripting tool. Each of these features changes how we work and what we can automate.
Developer tools in 2026
According to LLB Solutions’ analysis, the platform is moving toward full integration with GitHub for version control, Page Scripting, and testing frameworks for extensions and agents, as well as improved support for building solutions on top of Copilot. All signs point to an ecosystem where “craft-based” development without pipelines is increasingly far from the standard.
The AI factor
Business Central incorporates autonomous agents that perform repetitive tasks—from data entry to document review—and a Payables Agent capable of reading PDF invoices and automatically suggesting accounting entries. For developers, this introduces new integration and testing points that greatly benefit from automated pipelines; the complexity of the code we must maintain and test continues to grow.
How to adopt DevOps in Business Central in a smart way ABC
Being a senior Business Central developer in 2026 means mastering not only AL and business logic, but also delivery processes. Microsoft makes this easier to the point that there is no longer a technical excuse not to have at least basic CI: AL-Go aims to make continuous integration “virtually free in terms of investment” and allows partners to set it up without prior knowledge of pipelines, Docker, or PowerShell
Even so, the right answer is not “DevOps for everything at any cost.” As we have seen, the discussion in the community is no longer about “Should I adopt DevOps?” but rather “How do I size it intelligently according to my project?” The most effective strategy is to adopt a “tailored DevOps” approach that aligns practices with the scale, complexity, and lifespan of each project. Oversizing can erode competitiveness; undersizing can jeopardize maintainability.
If you are still maintaining your developments using completely manual methods, this is the time to explore these tools. You can start by creating a GitHub repository based on the official AL-Go PTE or AppSource templates and set up a basic build pipeline. You will quickly notice the difference in terms of confidence and consistency.
And you, in your experience with Business Central: have you already embraced AL-Go or some other form of automation, or do you still think that “if it works, better not touch it”? What have been your biggest obstacles when implementing CI/CD in your BC projects? I invite you to share and discuss it—one of the best ways to learn as a community is by comparing these experiences. I look forward to your comments!