使用Azure DevOps处理EF Migrations的问题与解决思路

1. 先改核心错误：别在CI管道里动态建迁移 #

• EF的迁移文件（Migrations文件夹下的.cs、.designer.cs还有快照文件）是项目代码的一部分，必须在本地开发环境用Add-Migration Name创建好，再提交到Bitbucket。
• 把CI管道里的dotnet ef migrations add命令删掉——这就是你每次发布报重复表错误的原因，管道每次跑都会生成新的迁移记录，数据库里已经有过的迁移又被执行一遍。

2. 让CI管道生成完整的迁移脚本 #

之前生成的脚本只有EFMigrationsHistory表，是因为没正确指定迁移范围。用下面的命令生成包含所有未执行迁移的脚本：

dotnet ef migrations script --idempotent --output migrations.sql --project 你的项目名.csproj --startup-project 你的启动项目名.csproj

• --idempotent：脚本会自动检查EFMigrationsHistory表，只跑没执行过的迁移，避免重复操作
• --output：指定生成的SQL脚本路径，方便后续发布阶段调用
• 管道里要配置好数据库连接字符串（可以用Azure DevOps的变量组存敏感信息），确保能正确读取DbContext

3. 发布管道执行迁移脚本 #

在Azure DevOps的发布阶段，用对应的数据库部署任务（比如Azure SQL Database Deployment），把生成的migrations.sql脚本部署到目标数据库：

• 选择生成的SQL脚本文件，填入目标数据库的连接字符串
• 确保执行脚本的账号有足够权限（比如db_owner或者ddl_admin）

4. 团队协作要守的规矩 #

• 所有人创建迁移后，必须把Migrations文件夹下的所有相关文件提交到Bitbucket
• 多人开发遇到迁移冲突时，要么合并迁移文件，要么回滚本地迁移，拉最新代码后重新创建
• 发布前先在本地拉取最新迁移文件，测试脚本没问题再触发CI/CD

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