// article
A Business Central AL pipeline is not complete because it produces an .app file. A production-grade pipeline proves where the package came from, which dependencies and Business Central artifacts were used, which checks passed, who approved release, and how the team can recover if deployment fails.
Microsoft's current plug-and-play DevOps solution for Business Central app development is AL-Go for GitHub. Microsoft maintains templates for both per-tenant extensions and Marketplace apps. Teams using another CI platform can implement the same controls, but they must own more of the orchestration.
Define the supported Business Central versions, countries/regions, extension type, dependency policy, branching model, and environments before writing pipeline YAML. A per-tenant extension and a Marketplace app may share compile and test stages, but their validation, signing, distribution, and approval paths differ.
Restore symbols and dependencies from declared sources, compile against the intended Business Central artifact, and archive the logs. The output package should map to one immutable source commit. Rebuilding the same release from an untagged workstation with a different symbol set is not a release process.
Run CodeCop and the analyzers appropriate to the distribution model. Marketplace candidates should include AppSourceCop and the technical-validation rules Microsoft documents. Treat analyzer errors as build failures unless a reviewed exception is recorded in source.
Deploy the app and its test dependencies to an isolated Business Central test environment. Run fast unit and business-logic tests on every pull request, then broader integration, upgrade, and performance scenarios before release. Microsoft recommends container-based environments for large test suites and CI/CD gates; production online environments are not a place to run automated tests.
Keep test code separate from the production app. Tests should be repeatable, unattended, and leave the environment in a known state.
Test both a clean install and an upgrade from supported production versions. A package that compiles can still fail when synchronizing schema, running upgrade code, resolving permissions, or installing a dependency. Record the exact starting app version and target environment version for every upgrade case.
Promote the tested artifact instead of compiling a new package for production. Store its checksum, manifest, source tag, analyzer results, test results, and release notes. Signing keys and deployment credentials belong in a protected secret store with narrowly scoped access.
Move the same artifact through development, test, customer sandbox, and production gates as applicable. Automate technical deployment steps, but retain an explicit business approval before a customer production change. For production, define whether the operation is install, upgrade, or rollback and capture the result.
Confirm the installed app version, upgrade completion, permission availability, critical workflows, job queues, integration health, and telemetry. A green deployment API response is not sufficient if background work is failing after installation.
AL-Go for GitHub reduces setup and stays current through Microsoft-maintained workflows. Azure DevOps, GitHub Actions, or another controlled runner can all execute a sound release model. The non-negotiable part is the evidence chain and customer protection, not the logo on the pipeline screen.
Bitta Apps can establish or repair AL engineering pipelines, add release-wave verification, and connect deployment evidence to integration operations for customer-owned and product extensions.