Azure App Service部署中Flyway长时迁移超时问题求解

方案1：将Flyway迁移与应用启动解耦，预执行迁移 #

• 把Flyway迁移从Spring Boot启动流程中剥离，单独执行：
  1. 打包独立的Flyway迁移工具包（用Maven/Gradle生成仅包含Flyway和迁移脚本的Jar包）
  2. 通过Azure CLI或CI/CD流水线在部署应用前先跑迁移：

     az webapp deploy --resource-group <你的资源组> --name <你的App Service名称> --src-path ./flyway-migration.jar --type jar --target-path /home/site/wwwroot/flyway-migration.jar
     az webapp run-command invoke --resource-group <你的资源组> --name <你的App Service名称> --command "java -jar /home/site/wwwroot/flyway-migration.jar"
     

  3. 迁移完成后再部署Spring Boot应用，此时应用启动时Flyway会识别到迁移已完成，不再执行耗时脚本。

方案2：利用部署槽位+预热机制 #

• 借助部署槽位的预热功能，让迁移在槽位内完成后再切换到生产环境：
  1. 创建一个部署槽位（比如staging槽）
  2. 在槽位配置里设置WEBSITES_CONTAINER_START_TIME_LIMIT=1800，同时开启槽位预热（在槽位的「部署槽位」设置中启用）
  3. 先把应用部署到staging槽，槽位会启动应用并执行Flyway迁移，只要在30分钟内完成，槽位就会处于就绪状态
  4. 迁移完成后，将staging槽与生产槽交换，生产槽直接使用已完成迁移的实例，避免启动时的迁移耗时。

方案3：优化迁移脚本本身 #

• 从根源缩短迁移时间：
  • 拆分大脚本为多个小脚本，分批次执行
  • 避免全表扫描、大规模数据修改操作，改用批量处理
  • 针对Azure数据库（如Azure SQL）添加合适索引，优化迁移语句的执行效率
  • 若无需验证，禁用Flyway的自动验证步骤，减少启动额外开销。

方案4：用Azure Functions触发迁移 #

• 专门创建Azure Function负责Flyway迁移：
  1. 在Function中集成Flyway并配置数据库连接
  2. 通过HTTP或定时触发器触发迁移执行
  3. 在应用部署前手动调用Function完成迁移，或者把调用步骤加入CI/CD流程
  4. 应用启动时Flyway检测到迁移已完成，直接启动服务。

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