从合并到主分支中排除文件

Question

环境：

我们使用 Bitbucket 进行存储库管理（和合并），使用 Jenkins 进行 CI/CD。构建具有开放拉取请求的分支并将其部署到临时环境（其中包括数据库的快照），在其中执行集成测试。主分支的处理方式类似，只是它也部署到“永久”环境以进行 QA 等。这是使用 Jenkins 脚本自动完成的。

PR 获得必要的批准并且上述构建/部署过程通过后，开发人员在 Bitbucket UI 中执行合并到主分支。

问题：

一些 PR 需要更改代码和数据库。如果数据库架构与代码期望的不同或者关键数据丢失，集成测试将会失败。

方法：

我们希望使用特定于更改的 SQL 脚本，在运行集成测试之前将临时构建环境中所需的数据库更改应用到数据库快照上。

一种方便的方法是在存储库中创建一个存根

db_changes.sql

文件，开发人员可以在功能/错误修复分支中修改该文件，该存根文件将由构建/部署脚本与分支的其余部分一起拾取，但排除它从合并到主分支。这将确保主分支的分支将产生一个空的

db_changes.sql

文件，并且当代码不需要它们时不会尝试数据库更改。

问题：

使用 git 属性为该文件指定合并策略的明显方法不适用于 Bitbucket。

集思广益替代方案：

一个想法是将默认合并选项（如果在 Bitbucket 上可以的话）更改为

recursive

，这表面上允许使用 git 属性进行合并策略。然而，看起来

recursive

可能比 ort

明显慢

。

另一种选择是为每个分支使用单独的数据库更改脚本，并采用命名约定将文件名与分支名称相关联，但这似乎很脆弱并且容易出现拼写错误。

请指教。

Answer 1

这不是版本控制层面要解决的问题。相反，您可以更改协调数据库更改的方式。

一种方便的方法是在存储库中有一个存根 db_changes.sql 文件，开发人员可以在功能/错误修复分支中修改该文件，该文件将由构建/部署脚本与分支的其余部分一起拾取，但排除它从合并到主分支。这将确保主分支的分支将产生一个空的 db_changes.sql 文件，并且当代码不需要它们时不会尝试任何数据库更改。

您所描述的是正在进行架构迁移。对数据库的每更改都是通过这种方式完成的，而不是临时修改固定的模式。该架构是通过在空数据库上运行每个更改来生成的。然后，您可以转储架构的快照。

例如，您的第一次架构迁移可能会设置您的基本表及其关系。在开发和测试中，这用于生成模式并创建数据库。数据库没有数据。

测试总是在没有数据的情况下开始。编写测试的开发人员使用factory_bot等工具来生成测试数据并填充数据库。在测试之间，数据库会以尽可能细的粒度被清空，通常是通过回滚事务来清空。这可以避免失败的测试弄乱数据库，每个测试都从已知的干净状态开始。

如果开发人员想要更改架构，他们会编写新的架构迁移。例如，分支可能包含带有

alter table

的架构迁移以添加新列。和以前一样，运行所有迁移都是为了创建用于开发和测试的数据库。

在生产中部署此更改意味着首先在临时数据库上运行架构迁移，该数据库确实具有与生产类似的示例数据（这可能是生产快照，但请小心将 PII 暴露给开发人员和测试人员）。一旦知道可以在登台上运行，迁移就会应用于生产。

通过这种方式，可以自动测试开发、测试和生产模式并保持同步。测试不会意外留下数据来迷惑其他测试。测试可以插入和删除他们想要的任何数据。分支机构可以根据需要对数据库进行任何更改。

许多 ORM 和框架都支持这种开箱即用的工作流程。