在基于主干的开发中，您的 terraform 管道看起来如何？答案

【问题标题】：How does your terraform pipeline look like with trunk based development?在基于主干的开发中，您的 terraform 管道看起来如何？
【发布时间】：2022-01-25 20:47:15
【问题描述】：

前几天我和一位同事在头脑风暴，关于如何利用基于主干的开发（功能/ -> 主控）部署到多个 AWS 账户。

从 master 部署到多个环境的想法困扰着我们，因为如何确定部署到何时何地？

我很想看看你们中的一些人如何解决这个问题。

例如您有 1 个主分支和 3 个单独的 aws 帐户（开发、登台和产品）。

【问题讨论】：

标签： amazon-web-services terraform terragrunt

【解决方案1】：

我想了很多。

使用基于主干的开发流程，我们假设基础设施与基础设施即代码一致（即代码反映环境的状态），我发现最简单/最清晰的方法是为每个环境都与模块相结合。

一些模块 v1.2.0

├── datalake (a component)
│   ├── dev (a terraform working directory) (some resources, also references some-module v1.2.0
│   └── prod (a terraform working directory) (some resources, also references some-module v1.1.0)
└── networks (a component)
    ├── dev (a terraform working directory)
    └── prod (a terraform working directory)

合并后，您应该自动应用更改。如果您担心，请实施检查以避免销毁和重新创建，但这应始终显示在您的规范计划中，作为 CI 的一部分，然后才能获得批准。

通过拥有这种模式并使用“无效的东西得到恢复”的方法。在将新实现复制到 prod 之前，您可以确保它们在 dev 中有效。

一些常见的替代观点是：

通过../common 目录拆分：
- 专业版：有利于避免漂移
- 缺点：开发中的快速迭代太糟糕了。
通过 TFvar 进行拆分：
- 专业版：简单且一致的环境是相同的，除了一些值（输入而不是资源），类似于常见的模块目录。
- 缺点：不允许（资源）漂移而不影响所有环境。

【讨论】：

感谢 Jake 的回复，唯一仍然困扰我的是 dev 和 prod 文件夹之间的代码重复。我最初在考虑包含一组代码的 master 分支，这些代码部署在不同的环境中，并使用 tfvars 为每个环境注入变量。我喜欢你的方法，我会记住的，谢谢！
如果您对同时更改所有环境的资源更改感到满意，则 Tfvar 可以很好地工作。否则，您需要将某种手动门部署到生产环境中。祝你好运，伙计。