我有一个Laravel项目(iOS应用程序的API)，目前正在建立一个持续集成服务器(Jenkins)来处理AWS的部署。我正在使用Capistrano、Packer和Terraform等工具来实现这一点。
目前，该应用程序有两个环境：暂存和生产。
然而，我正在努力寻找一种在这个系统中使用数据库的好方法。
基本上，我设想管道是这样的：
- 签出代码
- 运行测试
- 部署临时AMI并建立新的基础架构
- QA并将AMI部署到生产
但是，在第3步和第4步之间，我希望对生产部署进行一次"试运行"，也就是说，尝试迁移，并访问生产可能拥有的大型数据集。
所以我看到两个选项：
1) 当我们准备好进行QA时，导出生产数据库并将其导入到暂存中。然后运行"流程"(迁移、地形、封隔器等)。如果一切顺利，转到生产
PROS：
- 你可以在字面生产数据集上尝试所有东西，这样你就有信心事情会成功
- 您可以处理大型数据集，并查看与典型的暂存环境相比，由于存在大量记录，是否存在瓶颈
CONS：
- 最终，生产数据库可能会变得很大，并导出它每天，或者一天几次，可能会变得非常缓慢
- 与上述观点类似，这导致了非常缓慢的连续集成
2)不是从生产导入，而是为所有数据库模型编写可配置的种子程序，并根据QA的需要运行。
PROS：
- 根据特定部署的需要，您可以使用小型或非常大型的数据集为数据库种子
- 种子程序只是一个简单的脚本，可以很快运行
CONS：
-
你必须让你的播种机跟上你所做的任何模型更改。
-
一般来说，与从生产中导出实际数据集相比，此过程似乎更容易出现人为错误。
人们通常如何处理这一过程？
您的暂存环境希望看起来尽可能像生产环境，否则它就有点失去了拥有它的意义，因为很难对其进行QA或将其用于实际测试，而不会破坏生产。
因此，数据库迁移应该随代码一起移动，对底层架构所做的任何更改都应该与使用这些更改的代码同时提交，从而同时通过CI管道传播。
至于实际数据，我们定期拍摄数据库的快照(在AWS的RDS上运行)，然后将这些快照恢复到我们的"实时"环境中。这意味着我们的测试环境具有与生产类似的数据量，因此我们可以看到数据库迁移等因素的影响，以及在进入生产之前需要执行多长时间。
我们还有一些更精简的环境，用于运行广泛的自动化测试套件，但这些环境生成的数据很少，足以运行测试。
在我们的案例中，我们还处理个人身份信息，因此我们的快照过程实际上稍微复杂一些，因为我们还随机化了任何潜在的敏感数据，生成了新的姓名和联系方式等。
对您来说，很可能归结为从生产中真正恢复数据是多么痛苦。我想说的是，从这样做开始，当它变得太痛苦或太慢时，请考虑转而生成数据集，并确保它的大小足以模拟生产或让你更好地了解现实世界。
所以在你的情况下，我会开始这样的事情：
- Jenkins处理代码更改(例如在Git中合并到master)
- 单元测试在Jenkins的内存中运行
- 绿色构建然后触发AMI的Packer构建，然后对其进行适当标记
- 然后，Jenkins让Terraform使用生产中的最新快照(必要时经过消毒)和使用
aws_ami数据源自动获取的新AMI来构建您的暂存环境 - 如果您的测试通过了这个阶段，那么您就可以触发生产部署，让Terraform用新的AMI替换旧的AMI
我建议使用蓝色/绿色部署，使用此处概述的策略推出新的AMI，但这本身就是一个单独的问题(其他地方有大量资源)。