问题:持续集成/部署和数据库

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

目前,该应用程序有两个环境:暂存和生产。

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

基本上,我设想管道类似于:

1. 签出代码

2.运行测试

3. 部署 Staging AMI 并建立新的基础设施

4. QA 并将 AMI 部署到生产环境

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

所以我看到了 2 个选项:

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

优点:

• 你可以在文字生产数据集上尝试一切,所以你有信心一切都会成功

• 您开始使用大型数据集,并查看与典型的暂存环境相比是否存在大量记录导致的瓶颈

缺点:

• 最终,生产数据库可能会变得非常大,并且每天导出它,或者一天导出几次,可能会变得非常慢

• 与上述类似,这使得持续集成非常缓慢

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

优点:

• 您可以使用小型或大型数据集为数据库播种,具体取决于您对该特定部署的需求

• 播种机只是一个简单的脚本,可以很快运行

缺点:

• 您必须使播种机与您所做的任何模型更改保持同步。

• 一般来说,这个过程似乎更容易受到人为错误的影响,而不是从生产中导出实际数据集。

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

解答

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

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

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

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

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

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

所以在你的情况下,我会开始这样的事情:

1. Jenkins 获取代码更改(例如在 Git 中合并到 master)。

2. 单元测试在 Jenkins 的内存中运行。

3. 绿色构建然后触发 AMI 的 Packer 构建,然后对其进行适当标记。

4. 然后,Jenkins 让 Terraform 使用来自生产的最新(必要时经过清理)快照和使用aws_ami数据源自动获取的新 AMI 构建您的暂存环境。

5. 如果您的测试通过了这个阶段,那么您可以触发生产部署,其中 Terraform 用新的 AMI 替换旧的 AMI。

我建议使用蓝/绿部署来推出新的 AMI,使用诸如此处概述的之类的策略,但这本身就是一个单独的问题(其他地方有大量资源)。