The first approach to applying databases changes is as part of the release pipeline. When this is the case, the tool that is responsible for reading and executing the migration scripts is invoked using a step in the pipeline.

This invocation can be done using a custom script in PowerShell or another scripting language. However, this is error-prone, and with every change of tool, there is a risk that the scripts need to be updated. Luckily, for most of the migration-based tools, there are Azure Pipelines tasks that are readily available for starting the migration from the release.

For example, there is an Azure Pipelines extension available for applying Entity Framework Core migrations to a database directly from the dll file where they are defined. This task can be added to the release pipeline for updating the database, before the new application code is deployed.

Another variation is a split between the build and the release phase of an application. In this case, the migration scripts are exported as a separate build artifact, either directly from source code—if written in SQL—or after executing a tool that generates the necessary SQL scripts as output. This artifact is then downloaded again in the release phase, where it is applied to the database using an Azure Pipelines task for executing SQL.