太多指令碼將會毀掉持續交付

Electric Cloud的產品經理Avantika Mathur在上個月的倫敦Continuous Lifecycle大會上呈現了演講，談到了與持續交付管道中越來越多的指令碼相關的成本。除了維護成本，在將變更部署到生產環境之前，正在進行的活動缺乏可見性和可審計性也是另一個主要成本，但很多組織都沒有意識到這一點。

\\

要解決這個問題，首先需要識別問題，併為管道編配製定指導原則。Mathur推薦了這些原則：

\\

• 確保部署之間的可重複性和一致性\

• 將應用程式的定義與環境分開\

• 專注於環境之間的可移植性\

• 避免鎖定某些工具和技術（換句話說，確保通過實踐來指導工作，而不是工具）\

在避免指令碼蔓延方面，Mathur建議的方法是首先將指令碼重構為引數化的通用函式，然後在可能的情況下用可以完成相同甚至更好工作的工具替換它們。

\\

不過，同時處理大量指令碼可能具有一定挑戰性（從技術和人員的角度來看），並且效率低下（低投資回報率）。Mathur推薦了一種迭代方法。首先，通過價值流對映來識別那些減緩交付或混淆交付流程的中間瓶頸和依賴。這將有助於優先考慮哪些指令碼需要首先重構。Mathur還建議對現有指令碼進行分桶（配置、部署、測試自動化等）以便識別出重複任務，根據複雜性對它們進行分類以評估工作量，測算指令碼執行的頻率以估計潛在收益，最後再看看是否存在更好的替代方案可以降低成本。

\\

Mathur最先注意到這種“指令碼噩夢”的影響，80％的團隊工程時間用在了維護（而不是用於演進）或低效自動化的指令碼以及緩慢的流程上，而不是用於更快更安全地進行交付。工程師忙於維護指令碼，害怕更改脆弱的指令碼，執行內容缺乏可見性，冗長的審計準備流程，這些都是指令碼失去控制或管道編配工作不夠細緻的典型現象。

\\

總之，Mathur建議“將管道作為一種產品對待”，確保管道上的每一次變更都經過測試，並在進入“生產”環境之前經過全面評審（即可供所有人使用）。這也意味著要讓每個人都能看到管道，通過度量和基準來改進效能，並儘可能重用已有的部分。

\\

檢視英文原文：Too Many Scripts Can Kill Your Continuous Delivery