如何在将Web API项目通过VSTS部署到Azure时运行EF Core迁移

我之前部署.NET WebAPI时也碰到过一模一样的问题，折腾了好一阵才找到适配最新版本的靠谱方法，给你整理几个实用方案：

方案一：发布管道中添加脚本任务（最灵活） #

这是我最常用的方式，能精确控制迁移的执行时机：

• 打开你的发布定义，找到部署到Azure App Service的阶段，添加一个Azure PowerShell（Windows环境）或Azure CLI（跨平台）任务
• 选择对应的Azure订阅，然后在脚本框里填入以下内容（记得替换成你的项目信息和EF版本）：

  # 切换到构建输出的项目目录（路径根据你的工件结构调整）
  cd $(System.DefaultWorkingDirectory)/YourBuildArtifactDrop/ProjectName
  
  # 安装对应版本的EF工具（如果构建时没预装的话）
  dotnet tool install --global dotnet-ef --version 6.0.20
  
  # 设置环境变量（按需改成Staging/Development等）
  $env:ASPNETCORE_ENVIRONMENT = "Production"
  
  # 执行迁移（--project和--startup-project如果是同一个项目可以只写一次）
  dotnet ef database update --project ProjectName.csproj --startup-project ProjectName.csproj
  

• 关键提醒：要确保目标Azure App Service的应用设置里已经配置了正确的数据库连接字符串，不然迁移会找不到数据库。

方案二：通过App Service启动命令自动执行（最简便） #

如果不想加额外任务，这个方法一步到位：

• 在发布管道的Azure App Service部署任务中，找到「启动命令」配置项
• 填入以下命令：

  dotnet ef database update && dotnet ProjectName.dll
  

• 这样每次部署完成后，App Service启动时会先跑迁移，再启动WebAPI。不过要注意：如果迁移逻辑复杂耗时久，可能会触发App Service的启动超时，这时可以去App Service的配置里把启动超时时间调长一点。

方案三：构建时生成迁移脚本，发布时执行SQL脚本（最可控） #

适合需要审核迁移SQL、或者对数据库变更有严格管控的场景：

1. 构建阶段生成脚本：在构建管道里添加一个「Dotnet Core」任务，命令选ef，参数填：

   migrations script --idempotent --output $(Build.ArtifactStagingDirectory)/migrations.sql --project ProjectName.csproj --startup-project ProjectName.csproj
   

   --idempotent参数能生成幂等脚本，不管之前有没有执行过迁移，都能安全运行不会报错。
2. 发布阶段执行脚本：在发布管道里添加一个「Azure SQL Database Deployment」任务，选择目标数据库，然后指定脚本路径为$(System.DefaultWorkingDirectory)/YourBuildArtifact/migrations.sql，执行这个脚本完成迁移。

几个避坑要点 #

• 环境变量问题：你提到的ASPNETCORE_ENVIRONMENT总是Production的情况，要在Azure App Service的「配置」→「应用设置」里手动添加这个变量并设置对应值，或者在发布任务的「应用设置」里通过-ASPNETCORE_ENVIRONMENT Staging的方式传递，不要依赖默认值。
• 版本匹配：dotnet-ef工具的版本必须和你项目里的EF Core NuGet包版本完全一致，不然会出现兼容性错误。
• 权限问题：Azure DevOps的服务连接对应的账号，需要有目标数据库的db_owner权限（至少要有修改Schema的权限），不然迁移会失败。

内容的提问来源于stack exchange，提问作者dapperdandev