使用DevOps強化敏捷（上）

做者 | Christopher Lee & Sean D. Mack

譯者 | 舒適

若是您曾經對敏捷或DevOps的歷史、結構、原則或好處有過疑問，那麼您將在這篇文裏找到答案，本文被拆分兩篇，上篇主要介紹敏捷和DevOps的歷史、差別和好處。

敏捷和DevOps從表面上看多是不一樣的，但若是關注他們的目標，會發現它們其實很是類似。二者的目標都是更快地爲客戶創造價值並更快地改變市場需求。DevOps採用敏捷中介紹的原則，並將其擴展使用到代碼之外的部署和運維操做中。

敏捷和DevOps的目標是一致的，所以在實踐過程當中會發現它們有所重疊。在許多方面，DevOps和敏捷的交叉關係到協做文化以及從這種文化中產生的現代技術實踐和過程。連續測試和小批量生產等過程當中更容易看到了這一點，在使工做盡可能可見化的過程當中，公開工做流和系統遙測，有助於確保向客戶快速交付工做產品，能加速向客戶傳遞價值。

敏捷和DevOps專一於提供客戶價值，這不是爲了提供更多功能，而是爲了儘量快速有效地向最終客戶提供正確的增值功能。DevOps使用敏捷的概念並對其進行了擴展延伸，所以您能夠經過實現DevOps實踐來加強敏捷性。

什麼是DevOps？什麼是敏捷？

在開始研究DevOps和敏捷之間的關係以前，首先要對這些術語的含義有一個共同的理解。雖然有許多定義，但它們能夠從根本上理解爲一套原則，從中能夠衍生出工程師文化和實踐。

敏捷的存在時間比DevOps長，定義也更爲成熟。首次定義於2001年2月的《敏捷宣言》，該宣言包含了如下幾條定義：

• 我的和交互重於流程和工具
• 工做軟件重於公共文檔
• 與客戶協做重於合同談判
• 響應變化賽過遵循計劃

儘管已經有了對DevOps宣言的嘗試，但尚未哪個宣言可以得到敏捷宣言所具備的那種普遍接受度。做爲一個通常概念，DevOps重視協做，特別關注開發和運營團隊之間的交叉功能以及這兩個方面的責任。敏捷教練Anthony Gardiner說，「我測試，我編碼，我部署，我在週末起牀並修復錯誤——我讓個人代碼更好，因此我沒必要在週末起牀。」DevOps能夠被認爲是一種爲客戶提供價值的方法，專一於協做和小批量，聚焦持續集成，自動化，持續測試和持續交付。

雖然沒有單一的定義，Gene Kim、Kevin Behr和George Spafford在他們的開創性書籍《鳳凰計劃》中介紹了DevOps的「三種方法」。這三種方法是許多DevOps實踐的核心。

Kim後來在《DevOps Handbook》中對這些方法進行了擴展，他與Jez Humble和Patrick Debois合著了這本手冊。

這三種方法包括：

方法一	系統思惟	強調整個系統的性能，而不是特定工做或部門的性能——大到能夠是一個部門，小到能夠是單個貢獻者。
方法二	加強反饋循環	建立從右到左的反饋循環。以縮短和加強反饋爲流程改進計劃的目標，以便持續進行必要的修正。
方法三	持續實踐和學習的文化	創造一種能促進兩件事的文化：一是持續實踐、冒險和從失敗中學習；二是理解重複和實踐是精通某件事的先決條件。

歷史

追溯到20世紀90年代，敏捷已存在的時間比DevOps長得多，後者在將近20年後纔出現。然而，這兩套原則都源於精益製造，其歷史能夠追溯到20世紀40年代。雖然DevOps的流行度持續增加，但敏捷仍然比DevOps更廣爲人知。谷歌趨勢表示「敏捷」一詞的搜索量大約是「DevOps」一詞的三倍。

敏捷的根源能夠追溯到20世紀40年代的精益流程，其中包括看板，一種可視化豐田生產系統一部分工做流程的方法。限制理論也是後來發展起來的。然而，敏捷的軟件開發方法在20世紀90年代真正起步，當時一羣軟件開發人員常受到瀑布式開發方法中涉及的高度嚴格的流程的困擾。這些常致使軟件項目花費了數月甚至數年才致使失敗。在20世紀80年代和90年代，誕生了幾種軟件迭代開發方法做爲瀑布方法的替代，包括極限編程（XP）和看板。1995年，引入了敏捷開發的Scrum實踐。而後，在2001年Snowbird山度假村的著名會議上，一羣思想領袖齊聚一堂，共同編寫敏捷宣言。敏捷發展至今，其中許多變化和實踐都是從最初的宣言演變而來的，包括現代敏捷。雖然敏捷制定了整體原則，但實踐敏捷原則的方法有不少，Scrum和看板是最受歡迎的兩種（關於它們的區別，可閱讀《Kanban VS Scrum：哪一個是最好的敏捷項目管理框架》）。

DevOps是一套更爲新的原則，它源於精益製造中的一些相同概念。「DevOps」一詞於2009年首次推出，當時Patrick Debois在比利時舉辦了「Devopsdays」活動。2013年，Gene Kim（做者），Kevin Behr（做者）和George Spafford（做者）撰寫了他們的書《鳳凰計劃》，其中提出的許多內容構成了DevOps的基礎概念。2014年，隨着DevOps企業峯會的啓動，DevOps不斷擴展到企業環境中。今天，DevOps繼續與敏捷一塊兒成長和發展。

關鍵差別

雖然敏捷和DevOps具備不少一致性，但須要注意的是它們的側重點不一樣。敏捷主要關注應用程序的構建，而DevOps則將這一重點擴展到構建和運營應用程序。DevOps採用了敏捷的許多概念，並將這些概念擴展到構建過程以外並帶入生產。正是這個擴展致使了真正的差別。

若是說存在不一樣，那麼主要在於聚焦點的不一樣。敏捷教練Martin Corbett表示，「敏捷專一於分解工做，以儘快爲客戶提供更多價值，而DevOps專一於將代碼從構建擴展到部署的項目，例如持續部署。」此外，敏捷專一於構建工做軟件以及開發和QA之間的協做，而DevOps則專一於開發、QA和運營之間的協做。

雖然許多人都在尋找敏捷與DevOps之間的差別，但實際狀況是，這兩種方法具備很是類似的目標和基礎原則，而且最終具備比差別更多的類似性。

DevOps是敏捷的延伸

在許多方面，DevOps能夠被視爲敏捷的延伸，甚至是敏捷的天然演變。在瀑布開發流程中，有一個明確的交接（它是強制執行的過程）。敏捷做爲一個持續的過程，須要一種新的方法，DevOps有助於實現這種方法。

爲了實現精益和敏捷最佳實踐的核心小批量發佈，在DevOps中普及的全棧工程師的概念是這種需求的最佳答案。爲了減小交接，工程師必須悉知系統的全部部分，以便團隊中的任何成員都能理解操做要求，而無需交付給其餘團隊。一樣，跨職能團隊必須成爲常態，以便小型，獨立的團隊能夠提供功能齊全的產品，而無需向運營團隊進行額外的交接。

此外，敏捷的持續流程須要必定程度的構建和部署自動化。其中大部分都是在DevOps的CI / CD實踐和工具中提供的。CI / CD須要快速部署通過全面測試而且功能齊全的代碼給客戶。所以，很容易看出CI /CD是敏捷實踐所必需的天然演化。這些作法持續發展，使發佈週期時間進一步縮短，從數週到數天甚至數小時。

從另外一個角度考慮，若是您有一個只有在開發完成後才能開始的爲期兩週的QA週期，那麼在一兩週內就很難將代碼推出。一樣，諸如變動審批、釋放資源、硬件購買和安裝等須要耗費時間的事情，都會影響你按時推出代碼。更不用說，您可能還有不少的交接工做，或者有一個週期長又繁重的發佈過程。如何進行爲期兩週的迭代並進行爲期兩個月的發佈過程？對此的明顯答案是DevOps。

這並非說沒有DevOps就沒法實現敏捷。敏捷在DevOps以前好久就存在，而且確定有敏捷團隊不遵循許多DevOps實踐。正如Noah Cantor所說，「你能夠作敏捷實踐和DevOps實踐，但你不能採用敏捷原則或DevOps原則，由於它們太類似而不能分開。」並非說它們不可分割，只是敏捷做爲DevOps的前身，同時激發了DevOps的影響力。

好處

精益一直是DevOps的核心，就像敏捷是從精益中生長出來的同樣。DevOps也是如此，因此這二者有很大的共同點並不奇怪。DevOps採用Agile中的概念，並將其擴展到代碼部署以外。DevOps採用這些概念並將其應用於應用程序和服務的管理。它利用並優化了敏捷的原則，而且沿用了敏捷組織早已意識到的長處。

並非說爲DevOps而作DevOps，或者說爲敏捷而作DevOps。2017年DevOps狀態報告顯示，高性能DevOps團隊的部署速度提升了46倍，交付時間縮短了44倍，更改失敗率下降了5倍，平均恢復時間縮短了96倍（MTTR）。在具備成熟DevOps實踐的組織中，這些數字顯然被低估了。

當咱們查看敏捷和DevOps重疊的每一個區域時，DevOps放大了敏捷實踐，咱們但願您可以採起一些具體措施來推進組織的發展。構建協做的最關鍵步驟之一是制定共同目標。有了共同的目標，您能夠確保開發，運營，QA都一致朝着同一目標努力。

小批量交付爲推進DevOps實踐加速組織提供了另外一個絕佳機會。在Scrum或看板等流程中，要將操做任務和操做思想集成到工做中。若是您正在使用Scrum，您也能夠考慮使用看板，它更容易適應操做流程。

不管使用哪一種方法進行小批量交付，您均可能但願確保使用相同的系統來跟蹤整個團隊的工做。經過統一跟蹤系統，您能夠確保不積壓工做，並真實反應全部計劃內和計劃外工做，讓您更容易地使工做可見。做爲敏捷的一個關鍵原則，咱們還能夠擴展使工做可見的概念，以顯示運營工做、系統操做和架構支持等工做。組織還能夠經過信息輻射體（好比看板）跨團隊分享這些信息。

當您着眼於構建更具協做性的文化時，要把每一次失敗都看成組織學習的機會。在這個文化中創建一些儀式，好比無可指責的過後反思、黑客馬拉松和失敗獎勵等。

對於本文中討論的重疊，存在組織上的含義。在敏捷和DevOps中包含QA意味着咱們必須開始構建跨職能團隊，並培養具備普遍知識技能的人員。這種重疊是隨着「全堆棧工程師」的概念而發展起來的。雖然每一個人都知道一切可能不現實，但咱們固然能夠努力確保團隊中的每一個人都有共同的責任和目標，包括質量和運營，若是他們樂於負責和學習的話。

有許多方式能夠採用敏捷原則並使用DevOps強化它們，但最重要的是組織文化的一致性。若是團隊在目標上沒有保持一致，那麼敏捷中規定的團隊方法將不能擴展到部署之外的操做中使用。若是全部技術交付團隊都遵循相同的目標，便可當即開始打破這些組織之間的孤島。若是咱們能夠經過敏捷開始打破組織孤島並經過DevOps強化這項工做，咱們將擁有真正的高性能組織。

『因爲篇幅緣由，本文被拆分兩篇，下一篇主要將介紹DevOps和敏捷之間的幾個共性，歡迎你們持續關注。』