在构建类似应用程序持续交付的基础设施持续交付流水线时，有一些重要的方面需要考虑。
译自 Questions to Ask about the IaC in Your CI/CD Pipeline 。
许多工程团队在支持软件开发生命周期时，采用类似的方法来交付基础设施。
为了缩小基础设施配置方式和应用环境部署方式之间的差距，许多DevOps团队会直接将基础设施即代码(IaC)模块连接到他们的CI/CD平台。
目标是创建一个与软件开发和交付过程直接织在一起的持续基础设施流水线，类似于用于应用程序持续交付的CI/CD流水线。
这很容易理解。开发团队需要快速部署基础设施，他们没有时间了解基础设施配置的细节。许多人对IaC工具也不够熟悉，无法从一开始就使用。
从理论上讲，将IaC模块插入CI/CD工具应该消除开发人员必须了解IaC配置中的语法和逻辑的需要。当开发人员和测试人员在流水线中执行工作时，基础设施会被部署以支持每个步骤。
但是，在采取这种方法之前，请确保思考几个重要的问题。
虽然在CI/CD流水线中使用基础设施即代码可以加快团队速度，但也会导致运维团队对资源消耗、使用和费用累积失去视野。
这对用于测试、调试和分阶段的短暂环境尤其相关。如果CI/CD流水线正在大规模部署云资源，那么这些阶段完成后，谁负责终止它们？如果想知道哪些环境正在运行，是谁启动的，以及它们正在产生的实时成本，该从哪里查起？
在争分夺秒地加速运维的过程中，可见性往往被牺牲。这使基础设施资产的端到端管理和成本控制变得困难。
面对截止日期的压力，一些团队可能会走捷径，将云帐号凭证、证书和其他密钥硬编码到基础设施即代码模块中，以便团队成员获取所需的访问权限。
仅靠基础设施即代码在CI/CD流水线中交付基础设施可以大大加速基础设施即代码模块的创建，但并不能更容易地安全访问云基础设施。这是一个应该避免的严重风险。
在不同生命周期阶段维护一致的配置可能具有挑战性，这会导致过时的测试环境扰乱结果并重新工作。
基础设施即代码工具只在源文件发生配置更改时指出。如果实时环境发生更改，开发人员将花费大量时间来理解部署失败的原因。
配备基础设施对DevOps生产力来说是双刃剑。一方面，频繁的环境部署有利于云成本效率，因为这表示团队会在不再需要时解除短暂环境。
另一方面，高需求部署可能意味着DevOps团队正忙于基础设施配备工作单，这会降低开发速度。
即使使用基础设施即代码，为支持CI/CD流水线提供环境所需的编排工作也可能非常可观。请务必考虑支持流水线的环境所涉及的工作量。
通过CI/CD流水线扩展基础设施即代码可能导致所谓的配置混乱。
跨git仓库管理的基础设施缺乏集中执行标准的方式，这使得难以知道团队是否正在部署经批准的云配置。
操作也是如此。如果要对短暂环境的最大运行时间设限，如何在受数十甚至数百个基础设施即代码配置支持的多个流水线中执行？
随着客户越来越多地采用云原生开发，我们看到复杂性挑战变得更加普遍。多年来，我们一直在帮助DevOps和平台团队自动化和编排基础设施组件，以应对复杂性并提高交付速度。
这让我们与客户一起构建了平衡云速度与可见性和治理的云控制平面方案。归根结底，您的开发团队应该能够加快速度，而不会牺牲对云资源使用方式的控制。