小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
三、本地运行代码
对于应用代码，我们可以很容易在本机构建环境，模拟实际业务场景进行测试，对于基础设施相关的代码，我们当然无法在本机再创建计算实例和数据库实例等。但了保证在生产环境的健壮性、安全性，还是很有必要在正式部署之前进行测试，基于Terraform，我们能手动测试其的唯一方法是在沙箱环境中运行它。
所谓沙箱环境，比如申请专用于开发的云资源操作账户，然后再进行相关的apply操作，最后再使用Curl等工具去验证部署的是否成功。
四、进行代码更改和提交评审
进行代码更改当然指的是代码的迭代变化，变化后，需要部署验证测试。这一部分强调在验证过程中，如何节省验证时间？核心主旨在可以并不进行全阶段的验证，可以选择性的验证，比如可以选择性的不创建资源、销毁资源，只是做应用层次的部署，通过这样的方式可以大大地减少反馈时间，提高效率。
提交代码并评审这一部分内容在应用代码开发时，很多开发团队都是遵守的，核心就是创建pull request完成代码评审。团队作战大家需要遵守同样一套编码准则、代码风格，通过代码评审这样的方式能达到这样的目的。
五、自动化测试
跟应用程序代码一样，使用自动化测试，能满足持续集成（CI）。即通过拦截脚本，在每次提交后触发CI服务器中的自动化测试流程，并在pull request请求中显示测试的结果。为此我们要做好两件事：
- 为Terraform代码编写单元测试、集成测试和端到端的测试
- 使用
Atlantis开源工具，在代码提交时自动运行terraform plan命令，并将 plan命令的输出添加到pull request的注释中。
六、合并和发布
当代码更改和计划输出通过团队成员的评审，并完成所有测试之后。你可以将更改合并到master分支中并发布代码。与应用程序代码流程类似，可以使用Git标记创建发布的版本。
因为Terraform支持从Git存储库直接下载代码，所以特定标签的存储库状态就是将要部署的、不可变的、版本控制的工件。
七、部署
上面代码编写，版本控制，验证、自动化测试完成后，就要开始部署。部署Terraform代码有一些优化和注意事项，以让工作更加高效。
7.1 部署工具
本身Terraform是一个工具，但在一些方面有局限性，还有一些部署工具包括Atlantis（用于pull request）、Terraform Enterprise（提供UI、管理变量、机密和访问权限）、Terragunt（部署功能增强）、甚至脚本都能较好地改善整个部署管理流程。
7.2部署策略
Terraform本身不提供任何部署策略，需要自己开发模块支持零停机、滚动部署、蓝绿部署、金丝雀部署。但因为其语言本身的局限性，能做到的控制能力是很有限的，所以需要花心思去设计。比如策略性地重试、核心关注Terraform的状态错、对于锁释放出错要有兜底方案等等。
还有一些其它的注意事项，比如应当有一个独立的部署服务器，而不是在开发人员机器上操作；并且对CI服务器应该进行严格的权限控制等等。