After the build pipeline finishes, you can use the release pipeline to deliver or deploy the build artifacts or do other actions that you want. To create a new release pipeline, go to the Release section and click on New Release pipeline. Because there is no template for Business Central release pipelines, begin with an empty job.

Each release pipeline is created with the following:

• Artifacts: This could be the output of the build pipeline, an Azure DevOps Git repository, a GitHub repository, a TFVC repository, an Azure artifact, an Azure container, a Docker Hub repository, or a Jenkins job.
• Stages: Each stage is a separate process that can be executed on different agents and can be triggered by different events.
• Variables: These are the same as in build pipelines.

For each artifact, you can define triggers to start the pipeline. It could be each time the artifact is updated (continuous deployment) or on a given schedule (such as nightly releases).

At each stage, you can set pre-deployment conditions and post-deployment conditions:

• Pre-deployment conditions: These include the following:
  • After release: This triggers when the selected artifact is deployed or on a given schedule.
  • After stage: This triggers when another stage is finished.
  • Manual only: Someone must trigger the deployment in the portal.
  • Pre-deployment approvals: Selected users must approve the deployment to this stage.
  • Gates: These are automated processes that can approve the deployment according to certain conditions (for example, when there are no errors after release to the previous stage).
• Post-deployment conditions: These include the following:
  • Post-deployment approvals: Selected users must approve that the release stage succeeded and that the release can continue.
  • Gates: Automated processes can approve the stage release.
  • Auto-redeploy trigger: You can trigger redeployment when needed; for example, after the stage fails, you can redeploy the last successful deployment. This could be useful for restoring to the last known working version.

Here's an example of a release pipeline for Dynamics 365 Business Central:

Each stage is deploying the app (and running tests) to a different version of the Business Central sandbox (the current version, the future version, and the master version). If everything is OK, the app is deployed to the QA environment for user testing. If the tests succeed, the app is signed by a certificate and stored on the server for later use (to be sent to AppSource) or is deployed to the target environment (a per-tenant app). This is what the YAML pipeline is about.