在構建類似應用程序持續交付的基礎設施持續交付流水線時，有一些重要的方面需要考慮。

譯自 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生產力來說是雙刃劍。一方面，頻繁的環境部署有利于云成本效率，因為這表示團隊會在不再需要時解除短暫環境。

另一方面，高需求部署可能意味著DevOps團隊正忙于基礎設施配備工作單，這會降低開發速度。

即使使用基礎設施即代碼，為支持CI/CD流水線提供環境所需的編排工作也可能非常可觀。請務必考慮支持流水線的環境所涉及的工作量。

如何使云操作標準化?

通過CI/CD流水線擴展基礎設施即代碼可能導致所謂的配置混亂。

跨git倉庫管理的基礎設施缺乏集中執行標準的方式，這使得難以知道團隊是否正在部署經批準的云配置。

操作也是如此。如果要對短暫環境的最大運行時間設限，如何在受數十甚至數百個基礎設施即代碼配置支持的多個流水線中執行？

隨著客戶越來越多地采用云原生開發，我們看到復雜性挑戰變得更加普遍。多年來，我們一直在幫助DevOps和平臺團隊自動化和編排基礎設施組件，以應對復雜性并提高交付速度。

這讓我們與客戶一起構建了平衡云速度與可見性和治理的云控制平面方案。歸根結底，您的開發團隊應該能夠加快速度，而不會犧牲對云資源使用方式的控制。