持续集成/部署和数据库

Question

我有一个 Laravel 项目（iOS 应用程序的 API），目前正在设置一个持续集成服务器 (Jenkins) 来处理 AWS 的部署。我正在使用 Capistrano、Packer 和 Terraform 等工具来完成此任务。

目前，该应用有两种环境：暂存和生产。

但是，我正在尝试找到一种在此系统中使用数据库的好方法。

基本上，我设想管道类似于：

1. 签出代码
2. 运行测试
3. 部署暂存 AMI 并建立新的基础架构
4. QA 并将 AMI 部署到生产环境

但是，在第 3 步和第 4 步之间，我希望对生产部署进行“试运行”——也就是说，尝试迁移，并访问生产中可能拥有的大型数据集.

所以我看到了 2 个选项：

1) 当我们准备好进行 QA 时，导出 Production DB 并将其导入 Staging。然后运行“进程”（迁移、terraform、packer 等）。如果一切顺利，进入生产阶段

优点：

• 您可以在文字生产数据集上尝试一切，因此您有信心一切都会奏效
• 您开始使用大型数据集，并查看与典型暂存环境相比是否存在大量记录导致的瓶颈

缺点：

• 最终，生产数据库可能会变得非常大，并且导出 每天或一天几次，可能会变得非常缓慢
• 与上述类似，这会导致持续集成非常缓慢

2) 不要从生产环境中导入，而是为所有数据库模型编写可配置的播种器，并根据 QA 的需要运行。

优点：

• 您可以使用小型或大型数据集为数据库播种，具体取决于您对该特定部署的需求
• 播种机只是一个简单的脚本，可以非常快速地运行

缺点：

• 您必须让播种机及时了解您所做的任何模型更改。

• 一般而言，与从生产中导出实际数据集相比，此过程似乎更容易出现人为错误。

人们一般如何处理这个过程？

Answer 1

您的暂存环境希望看起来尽可能地像生产环境，否则它会失去拥有它的意义，因为很难对其进行 QA 或将其用于实际测试您不会中断生产。

因此，您的数据库迁移应与代码一起移动，并且您对底层架构所做的任何更改都应与使用这些更改的代码同时提交，从而同时通过您的 CI 管道传播。

对于实际数据，我们会定期拍摄数据库快照（在 AWS 中的 RDS 上运行），然后将这些快照恢复到我们的“实时”环境中。这意味着我们的测试环境拥有与生产环境相似的数据量，因此我们可以看到诸如数据库迁移之类的影响以及在它投入生产之前执行多长时间。

我们还有一些更精简的环境来运行广泛的自动化测试套件，但这些环境生成的数据最少，足以运行测试。

在我们的案例中，我们还处理个人身份信息，因此我们的快照过程实际上稍微复杂一些，因为我们还会随机化任何潜在的敏感数据，生成新的姓名和联系方式等。

对您而言，可能归结为真正从生产中恢复数据是多么痛苦。我会说从这样做开始，当它变得太痛苦或太慢时，请考虑转而生成数据集，并确保它的大小足以模拟生产或让您对现实世界有一个很好的了解。

所以在你的情况下，我会开始这样的事情：

1. Jenkins 获取代码更改（例如在 Git 中合并到 master）。
2. 单元测试在 Jenkins 的内存中运行。
3. 绿色构建随后会触发 AMI 的 Packer 构建，然后对其进行适当标记。
4. Jenkins 然后让 Terraform 使用来自生产环境的最新（必要时经过清理）快照和使用 aws_ami 数据源自动获取的新 AMI 构建您的暂存环境。
5. 如果您的测试通过此阶段，那么您可以触发生产部署，其中 Terraform 将旧 AMI 替换为新 AMI。

我建议使用蓝/绿部署来推出您的新 AMI，使用诸如 here 概述的策略，但这本身就是一个单独的问题（其他地方有大量资源）。