创建CI/CD流水线中的IaC前，需要考虑哪些事项？
许多软件工程团队通常会遵循相似的方法来交付基础设施以支持软件开发生命周期。为了缩小基础设施配置方式与应用程序环境部署方式之间的差距，许多 DevOps 团队将其基础设施即代码（IaC）模块直接连接到其 CI/CD 平台。其目的是创建一个直接融入软件开发和交付流程的连续基础设施流水线，类似于用于持续交付应用程序的 CI/CD 流水线。
原因很容易理解。开发团队需要快速部署基础架构，他们没有时间了解配置的细微差别。许多人根本不熟悉 IaC 工具，因此无法在第一时间进行部署。
从理论上讲，将 IaC 模块插入 CI/CD 工具应该使开发人员无需了解 IaC 配置中使用的语法和逻辑。当开发人员和测试人员在整个流水线中执行其工作时，会部署基础设施以支持每个步骤。
不过在采用这种方法之前，有几个重要的事项需要明确。
如何跟踪资源利用率？
虽然在 CI/CD 流水线中部署 IaC 可以帮助团队更快地移动，但它会使运营团队忽视资源消耗、使用情况和成本应计情况。
这对于用于测试、调试和暂存的临时环境尤其重要。如果 CI/CD 流水线正在大规模部署云资源，那么谁负责在这些阶段完成后终止它们？如果您想了解当前正在运行哪些环境、谁启动了这些环境，以及这些环境给您带来的实时成本，应该从哪里开始下手？
在急于加速运维的过程中，通常会牺牲可观测性**。这使得基础设施资产的端到端管理和成本控制变得困难**。
团队是否共享云帐户凭据和密钥以获取访问权限？
面对按时完成任务的压力，一些团队可能会走捷径，将云帐户凭据、证书和其他密钥以硬编码的形式放到 IaC 模块中，以便为团队成员提供所需的访问权限。
仅依靠 IaC 在整个 CI/CD 流水线中交付基础设施会快速加速 IaC 模块的创建，但并不能更轻松地分发对云基础设施的安全访问。这是一个需要避免的严重风险。
如何确保 IaC 模块是最新的？
在生命周期阶段保持一致的配置在较大规模上可能具有挑战性，导致测试环境过期并需要返工。IaC 工具仅标识何时对源文件进行配置更改，这可能难以跟踪。如果实时环境发生更改，开发人员将花费大量时间来尝试了解其部署失败的原因。
DevOps 团队在预配基础架构上花费了多少时间？
对于 DevOps 的工作效率而言，基础设施置备（provisioning） 是一把双刃剑。一方面，频繁的环境部署对云成本效益来说是一个积极的信号，因为这表明当不再需要短暂环境时，团队会将其停用。
另一方面，对部署的高需求可能意味着您的 DevOps 团队需要繁忙地处理基础设施置备工单，这会降低开发速度。
即使在使用基础设施即代码时，交付支持 CI/CD 流水线的环境所需的编排工作量也可能相当大。请务必考虑支持流水线的环境的内容以及交付流水线所需的工作。
如何将云运营标准化？
随着越来越多的企业采用云原生开发，复杂性挑战变得越来越普遍。开发团队如何在不牺牲对云资源使用方式的控制的前提下加快速度，成为需对企业需要解决的问题。
通过 CI/CD 流水线扩展 IaC 可能会导致配置混乱。在 git 仓库管理的基础架构缺乏一个执行标准的中心点，因此很难了解团队是否部署了经批准的云配置。云运营也是如此。如果要为临时环境要求最大运行时，需要考虑在数十甚至数百个 IaC 配置支持的多个流水线中强制实施。
参考链接：
https://thenewstack.io/questions-to-ask-about-the-iac-in-your-ci-cd-pipeline/