Because the life cycle of business case apps is short and the cadence with which you are deploying new versions should be much higher than in the past (before the AL era), you cannot build, test, and deploy the app manually.

To automate this part of the life cycle, you can use Azure DevOps Pipelines, which will build, test, and deploy for you. You feed the pipeline on one side with the source code you are producing, and at the other end, you have a tested application, which can be even automatically delivered or deployed. Right now, there are two types of pipeline:

• Build pipeline: The input is the source code, and the output is the application and other artifacts.
• Release pipeline: The input is the output produced by the build pipeline, and the output is a tested application delivered or deployed to selected places.

The plan is that there will be one multi-stage pipeline instead that will cover the whole process. Consider the following diagram:

During the build stage, you are working with the source code and producing the product/application and testing it. In general, running tests on an application doesn't require the application to be deployed somewhere. For Dynamics 365 Business Central, it differs, and you need to deploy the app to a server to be able to test it—whether you use containers for this or not doesn't matter.

In the release pipeline, you are trying to deliver or deploy the application to different environments (the current version, the next version, different localizations, a new environment, or an environment with the previous version to test upgrades of the data, for example), test it in the environment, and carry out other steps that you need to deliver/deploy the app. This allows you to be able to deliver or deploy the application any time you want with as little manual input as possible.

Everything related to the work items you put into your commits or pull requests is transferred through the pipelines and, on each release, you can see all of the work items related to the release. This helps you to identify and describe the changes that are part of the specific version of your application, and the list could be automatically delivered with the application.