Databricks多环境下声明式与命令式对象的变更传递问询

1. 修改数据库后，仅修改Terraform脚本能否被检测并应用？ #

可以，但前提是Terraform配置与数据库实际状态严格映射。Terraform的核心逻辑是状态对比：执行terraform plan时，它会将本地配置、远程状态文件与数据库实际状态做三方比对，识别出差异后生成变更计划，执行terraform apply即可将配置同步到数据库。

需要注意：如果有人直接手动修改数据库（比如删了一个schema）但未更新Terraform脚本，下次执行apply时，Terraform会自动尝试将数据库恢复到脚本定义的状态，这可能和手动变更冲突，所以要严格禁止直接操作生产库。

2. 仅通过分支间的Pull request是否足以传递这些变更？ #

足够，但必须搭配对应的CI/CD流程落地。每个环境绑定对应分支（dev/test/prod），变更流程遵循：dev分支修改→PR到test分支→测试通过后PR到prod分支。

关键动作要落地：

• 每个PR必须触发terraform plan校验，确认变更符合预期，避免破坏性修改合并到上游分支。
• 分支合并后自动触发对应环境的terraform apply，确保变更快速同步到目标环境。
• 禁止直接修改prod分支，所有变更必须从dev逐步向上流转，保留完整的审计轨迹。

3. tables、views、存储过程等命令式对象应如何定义？ #

Terraform更擅长管理database、schema这类声明式基础资源，对于表、视图、存储过程这类对象，推荐两种方案：

• 直接用Terraform数据库资源：借助对应数据库的提供者（比如postgresql_table、mysql_view），在配置文件中声明对象结构。适合简单的表、视图，但复杂存储过程需要把SQL代码嵌入配置，维护性较差。
• 搭配数据库迁移工具：用Flyway、Liquibase这类工具管理版本化的SQL脚本，Terraform仅负责创建database和schema，迁移工具负责执行表、视图、存储过程的创建与更新。这种方式更适合复杂的SQL逻辑，脚本独立维护，版本追溯更清晰。

4. 这类对象的环境间变更应如何传递？ #

和Terraform配置的分支流转逻辑对齐，保证变更顺序一致：

• 在dev分支修改迁移脚本或Terraform数据库资源配置，提交后CI/CD自动部署到dev环境做功能验证。
• 验证通过后，发起PR到test分支，触发test环境的迁移/部署，完成集成测试。
• 测试无问题后，PR到prod分支，执行prod环境的迁移操作。

注意事项：

• 所有数据库变更必须做可逆性评估，生产环境避免执行不可逆操作（比如直接删除字段）。
• 迁移工具按版本顺序执行脚本，确保每个环境的变更步骤完全一致，不会出现状态不一致的情况。

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