Liquibase在DevOps（CI/CD）测试预生产环境删表重建是否为最佳实践？

这种做法不属于最佳实践，原因如下：

• 破坏环境一致性：预生产环境的核心作用是模拟生产环境的变更流程，生产中绝对不会采用删表重建的方式执行数据库变更。如果预生产每次都从头重建，就无法验证增量变更的兼容性、数据迁移逻辑等生产场景中会遇到的问题，等于失去了预生产环境的验证价值。
• 降低流水线效率：删表重建全量DDL/DML会消耗大量时间和资源，尤其是当微服务数量多、数据库表结构复杂时，会显著拉长CI/CD流水线的执行周期，影响开发测试的迭代速度。
• 丢失测试数据价值：测试环境中往往存在精心构造的测试数据（比如边界场景、复杂业务流程数据），每次重建都会清空这些数据，需要重复导入，增加额外工作量，也无法支持依赖历史数据的持续集成测试。
• 掩盖变更集潜在问题：全量重建会跳过增量变更时才会暴露的问题，比如变更集的执行顺序错误、数据迁移脚本的兼容性bug、幂等性缺失等。这些问题在预生产阶段没被发现，到生产环境执行增量变更时就可能引发故障。

更合理的替代方案 #

• 坚持增量变更流程：保持Liquibase变更集的幂等性，每次流水线执行时仅运行未应用的变更，和生产环境的变更逻辑完全对齐，提前暴露生产中可能遇到的问题。
• 按需触发环境重置：不要将删表重建设为流水线默认步骤，而是提供手动触发的重置选项，仅在必要场景（如大版本重构、变更集彻底调整）时执行。
• 独立管理测试数据：使用专门的测试数据工具生成或恢复测试数据，在增量变更完成后自动同步或补充数据，既保证环境干净，又保留测试数据的价值。

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