想要改進您的敏捷流程嗎？ 請關注容器DevOps - thenewstack

banq發表於2021-08-10
敏捷dev

在過去十年中幾乎無處不在的敏捷軟體開發是一場革命。與瀑布式開發不同，其長週期需要提前六到九個月進行規劃，敏捷進來了，只需要提前兩到四個星期規劃快速迭代，每個迭代都可能是可交付的。至少，這就是將敏捷賣給管理層的方式。
然而，它帶來了一個問題，大多數轉向敏捷的組織直到他們的第一個衝刺結束時才發現。問題在於，快速迭代的能力取決於出色的質量保證 (QA) 自動化，它可以在數小時內完成迴歸測試，而傳統瀑布式測試需要幾個月才能完成。
僅僅良好的 QA 自動化不足以實現真正高效的敏捷開發過程，而且大多陣列織在自動化方面處於糟糕和不存在之間。縮小自動化差距的需求直接導致了對經驗豐富的自動化工程師的快速且不斷增長的需求。然而，有幸聘請了優秀的自動化工程師並消除了敏捷流程的這一障礙的組織發現了另一個主要障礙：大量的質量自動化需要大量的自動化環境。
建立敏捷開發所需的許多自動化環境可能是一項繁重的工作，尤其是在使用物理硬體時。許多組織不得不虛擬化他們的開發和測試環境，以從他們對自動化的大量投資中獲得最大價值，並推動他們的敏捷開發流程向前發展。
幸運的是，大約在這個時候，業界看到了私有云和公共雲以及基礎設施即程式碼的迅速崛起，所有這些都催生了 DevOps。
 

DevOps 和虛擬機器
DevOps 迅速成為推動敏捷軟體開發向前發展的下一個瓶頸，組織透過聘請 DevOps 工程師以及隨之而來的基礎設施即程式碼 (IaC) 投資來做出回應。但隨著 DevOps 工程師構建廣泛的 CI/CD 管道，主導框架是虛擬機器，無論是私有云中的 VMware 虛擬機器 (VM)，還是 AWS 中的 EC2 例項。
這就是問題所在。就其性質而言，VM 相對較重且笨重。要啟動一個，您必須首先製作一份 VM 模板的副本，這取決於所涉及的啟動和資料卷的大小，可能需要 10 到 20 分鐘或更長時間。然後啟動和穩定 VM 需要額外的幾分鐘。並行啟動多個虛擬機器實際上會減慢速度，因為它們經常競爭儲存 IOPS、CPU 和網路頻寬。
一個相對簡單的管道啟動構建環境，然後是單元測試環境，然後是迴歸測試環境，可能涉及建立和啟動多個 VM，需要幾個小時。最佳的敏捷自動化策略要求在每次提交時執行 CI 管道，例如上面概述的 CI 管道，這很容易意味著每天有數十個管道。在使用 VM 時，這可能是一個巨大的挑戰。
 

容器來了
作為 DevOps 基礎設施的虛擬機器的現代替代品是容器，它克服了阻礙虛擬機器的限制。容器非常輕量級，並且隨著作業系統程式的啟動而快速啟動。使用虛擬機器在 10 或 20 分鐘內啟動的管道可以在不到一分鐘的時間內開始執行容器。更重要的是，因為它們是輕量級的，容器需要的 CPU、網路和儲存資源要少得多，因此它們的執行成本比 VM 低。
沒有能力為每個單獨的提交處理 CI/CD 管道的 VM 基礎設施可能能夠透過將硬體重新用於 Kubernetes 和容器來處理使用容器的負載。容器使敏捷組織能夠在從自動化和 DevOps 投資中獲取全部價值方面向前邁出一大步。
事實上，前瞻性組織正在容器化他們的應用程式並在 Kubernetes 上執行他們的 CI/CD 管道以加速敏捷開發。為了從基於 Kubernetes 的 CI/CD 環境中獲得最大價值，將它們與容器原生儲存結合起來很重要。容器原生儲存支援卷的即時克隆和跨 Kubernetes 叢集的資料卷的即時訪問。
在這樣的環境中，Kubernetes 叢集可以輕鬆地專用於開發、測試、整合和暫存環境，這為 DevOps 工程師提供了最大的靈活性。測試資料可以在不同的管道之間克隆並在 Kubernetes 叢集之間無縫移動，減少管道執行的持續時間，同時保持不同環境之間的隔離。使用容器原生儲存，在 Kubernetes 叢集之間和管道階段之間移動資料所需的時間減少到僅僅幾秒鐘。
 
使用敏捷軟體開發方法的組織已經取得了長足的進步。自動化比以前更廣泛、更深入，DevOps 現在支援複雜的 CI/CD 管道，使組織能夠從自動化中獲得全部好處並加速開發。然而，使用虛擬機器的組織受到需要花費數小時執行和使用大量資源的管道的束縛。為了縮短管道的持續時間並執行更多管道，現代軟體開發組織正在使用容器原生儲存將其應用程式容器化並在 Kubernetes 上執行其 CI/CD 管道，以充分利用敏捷流程的優勢來加速軟體開發。

相關文章