当有一个团队使用terraform来管理云资源（通过共享的git仓库），并且大多数成员没有对状态文件的直接个人访问权限（出于安全原因）时，在循环拉取请求之前，有哪些实践可用于测试和调试变更（例如特性）提议？
没有状态文件（或管理员凭据），terraform是否可以在本地为与基本提交相关的 * 更改 * 生成推测性计划？或者是否有必要生成单独的推测性计划（对于主分支和新特性分支）然后执行 diff？Like、是否可以使用另一个推测性计划来代替状态文件？2或者标准工作流是否可以保持将未完成的工作推送到临时远程分支，持续集成管道配置为根据实际状态自动生成计划？
1条答案
按热度按时间sh7euo9m1#
我猜您打算创建如下工作流：
1.CI测试通过-〉我们会回来这里
1.代码由高级开发人员审查并接受
terraform apply如果是这样，让我们关注问题...
***
to test***地形变化意味着什么？根据具体情况，可能为：
terraform plan打印有效计划terraform apply在***测试***环境中工作（与生产环境分开，状态文件为空-请记住在测试后清理此文件）当然，第二种方法要好得多，但并不总是可以（或者说有意义）创建测试资源，通常可以通过在资源中设置一些不同的名称来实现。
测试可能并不意味着将更改应用于您的生产。
与计划的差异也不是最好的“测试”，因为两个
terraform plan运行一个接一个可能不同。