本文档提供了使用 适用于 Google Cloud 的 Terraform。
与其他形式的代码一样，将基础架构代码存储在版本控制系统中以保留历史记录并允许轻松回滚。
本指南未介绍 Terraform。如需了解如何将 Terraform 与 Google Cloud 搭配使用，请参阅 Terraform 使用入门。
使用默认分支策略
对于包含 Terraform 代码的所有代码库，请默认使用以下策略：
main分支是主要开发分支，表示最新批准的代码。main分支受到保护。- 开发是在从
main分支的功能和问题修复分支上进行的。- 将功能分支命名为
feature/$feature_name。 - 将问题修复分支命名为
fix/$bugfix_name。
- 将功能分支命名为
- 完成功能或问题修复后，使用拉取请求将其合并回
main分支。 - 为防止合并冲突，请先合并分支，然后再进行变基。
将环境分支用于根配置
对于包含直接部署到 Google Cloud 的根配置的代码库，需要安全的发布策略。我们建议为每个环境使用单独的分支。因此，可以通过合并不同分支之间的更改来部署对 Terraform 配置的更改。
允许广泛的公开范围
将 Terraform 源代码和代码库设为可供基础架构所有者（例如 SRE）和基础架构利益相关方（例如开发者）在工程组织之间广泛查看和访问。这样可以确保基础架构利益相关方能够更好地了解其所依赖的基础架构。
建议基础架构利益相关方在更改请求过程中提交合并请求。
永不提交密文
切勿将密文提交到源代码控制系统（包括 Terraform 配置）中。而是将其上传到 Secret Manager 等系统，并使用数据源进行引用。
请注意，此类敏感值可能仍会最终出现在状态文件中，也可能作为输出公开。
根据团队边界组织代码库
虽然您可以使用单独的目录来管理资源之间的逻辑边界，但组织边界和逻辑可确定代码库结构。通常，使用的设计原则是将具有不同批准和管理要求的配置分离到不同的源代码控制代码库中。为了说明此原则，提供了一些可能的代码库配置：
一个中央存储库：在此模型中，所有 Terraform 代码都由单个平台团队集中管理。如果有专门的基础架构团队负责所有云管理并批准其他团队请求的任何更改，则此模型效果最佳。
团队代码库：在此模型中，每个团队负责各自的 Terraform 代码库，在其中管理与其拥有的基础架构相关的所有内容。例如，安全团队可能有一个在其中管理所有安全控制的代码库，并且每个应用团队都有各自的 Terraform 代码库来部署和管理其应用。
对于大多数企业场景而言，按团队边界组织代码库是最佳结构。
分离式代码库：在此模型中，每个逻辑 Terraform 组件都会拆分到各自的代码库中。例如，网络可能有一个专用代码库，并且可能有一个单独的项目工厂代码库进行项目创建和管理。这在团队之间职责经常发生变化的高度分散化的环境中效果最佳。
示例代码库结构
您可以组合这些原则，将 Terraform 配置拆分到不同的代码库类型：
- 基础级
- 特定于应用和团队
基础代码库
基础代码库，包含主要中心组件，例如文件夹或组织 IAM。此代码库可以由中央云团队管理。
- 在此代码库中，为每个主要组件（例如文件夹、网络等）添加一个目录。
- 在组件目录中，为每个环境添加单独的文件夹（反映前面提到的目录结构指导）。
特定于应用和团队的代码库
为每个团队单独部署特定于应用和团队的代码库来管理其唯一的特定于应用的 Terraform 配置。
