小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
部署基础设施代码的工作流程，泛指使用任何
IaC工具（包括Terraform）编写的代码，用于部署除了单个应用程序之外的任意基础设施更改。例如部署数据库、负载均衡器、网络配置、DNS设置等。
一、整体流程
基础设施即代码，核心就是代码管理。
【第一步骤】
所以流程第一大部分就是代码管理。其全流程包括：
- 版本控制代码（Using VCS）
- 本地运行代码（Local First）
- 代码更改（Update）
- 提交更改以供评审（Commit And Review）
【第二步骤】
关于基础设施描述的代码修改完成后不能急于执行，当然还要走一下自动化测试。测试通过可进行接下来的步骤，未成功需要重新回到上一步代码管理进行修改操作。
【第三步骤】
测试通过后，就需要进行分支合并，运行等操作了。其全流程包括：
- 合并和发布
- 实施部署
整个流程似乎与应用部署的流程一致，但本质上确存在差异，包括代码更复杂，使用的工具更不容易理解。
二、版本控制
就像我们通过版本管理应用代码的习惯一样，我们在此基础上还有一些其它的要求。包括：
- 双库实践（实时代码库和模块代码库）
- 满足Terraform的黄金法则
- 避免多分支部署
2.1 双库实践
在应用代码中，我们也时常把公用的业务逻辑，统一的工具、或者Infrastructure相关的代码独立成包并单独上一个代码仓库进行管理。
需要至少两个单独的版本控制存储库来存储Terraform代码，包括：
- 模块代码库
- 实时代码库
模块代码库一个用于存储模块代码，一个用于存储实时基础设施代码。模块存储库用来保存已创建的、可重用的、版本控制的模块代码；另一个实时基础设施存储库存储了每种环境（Dev、Stage、Prod等）中部署的实际基础设施。
根据两个库不同的性质，所以模块代码库建议成立基础设施团队，专门研究创建可重用的，健壮的生产级模块。实时代码库可以让业务团队管理，利用这些模块，来完成他们的工作。
2.2 黄金法则
所谓黄金法则，是为了更好的维护代码，避免团队合作带来的问题。总的思想是：“实时存储库的主代码分支应该以1:1的形式完全代表生产环境中实际部署的内容”。其包括以下细则：
Terraform的代码即代表基础设施环境，不要试图再用其它方式管理环境- 尽量避免使用工作区来管理环境，强烈建议不同的环境用不同的文件和文件夹来定义，即所见即所有
- 能实际影响部署内容的只能是master，即环境所有的变化都应该体现到master主分支中
2.3 避免多分支部署
其实这一点在上面讲到的黄金法则中已经提到，在团队多人作战中，一定要使用主分支代码进行部署，如果多分支部署，很容易就造成冲突，虽然Terraform plan能帮我们在正式应用部署之前做预览，察觉到diff的存在，及时止损。但毕竟这样的风险点存在，确实会为生产环境带来很多不确定的风险项。
所以总的来说，因为真实世界只有一个，所以多个分支的Terraform代码并没有太大的意义。因此，对于任何共享环境（如Stage、Prod），请始终从单个分支进行部署。