本文要點
- 軟件開發流程中有兩種類型的決策：戰略和戰術。
- 爲了讓組織更好地實現流水線驅動，我們可以將有關編程工作的日常戰術決策更多地轉移到流水線中制定，不再讓人爲因素影響這些決策過程。
- 流水線中人爲因素帶來的瓶頸越少，組織用流水線驅動的效果就越好，從而實現真正的持續交付。
- 在流水線驅動的組織中，我們的角色還包括教會流水線自動制定決策。
- 爲了適應流水線驅動的工作方式，我們中的許多人將需要學習新的技能。
引言
組織怎樣才能實現像Netflix、亞馬遜和谷歌等公司的研發速度和敏捷性，從而每天都對生產代碼部署多次更改呢？
爲什麼這麼多大中型企業都沒能做到這一點呢？
如何實現真正的持續交付？
正像所有軟件問題的根源一樣，這個目標能否實現還是取決於人力因素的；更具體地說是人們在流水線中的工作方式。流水線能在多大程度上實現持續交付，取決於我們對它制定的期望。
流水線驅動的文化對流水線和文化都提出了要求，所以我們先來談談流水線。
流水線
一條流水線是一個或多個自動化任務或“作業”的組合，它們以特定順序運行以生成某個結果。這個結果通常由兩件事組成：
- 判斷結果：流水線通過、失敗或給出不確定的結果（這裏永遠都應該使用“失敗”/“通過”，不能用“不確定”。我將在後文具體說明原因）。
- 所有相關工件：已部署的應用程序、二進制文件、日誌文件等我們關心的所有內容。
任務
本質上來說，任務是一個命令行（shell）腳本或程序，在某臺機器（本地或雲端）上自動運行，執行一些任務（有時候很多任務彼此相關，比如編譯、運行、測試等），並返回一段特殊的命令行“退出代碼”。
通常來說命令行中的零退出代碼表示成功。任何非零退出代碼都表示失敗。由程序或腳本決定退出代碼是哪一種。
CI/CD服務器
像Jenkins這樣的工具（一般稱“持續集成服務器”或用於“持續交付”的“CI/CD服務器”）充當這些任務之上的抽象層。CI服務器讓我們可以輕鬆地運行這些任務（基於特殊的代碼提交觸發器或規劃方案），並監聽任務的退出代碼及其輸出（日誌）。
然後服務器會解析日誌，併爲我們提供一個友好的UI來顯示結果、錯誤日誌和各種工件。
CI/CD服務器使我們能在一處集中管理任務並監視其運行進度，還能同時在許多機器上運行很多任務（有時稱爲“構建代理”）。
流水線驅動
所謂“流水線驅動”，是說我們希望更多地依靠流水線制定與代碼及其工件相關的技術決策（判斷），然後讓流水線立即根據這些決策儘可能自主地行動。
在軟件開發行業，人們通常要做出兩種不同類型的“決定”：
- 戰略判斷，例如：
- “我們應該製造這種產品嗎？”
- “我們應該關注這個功能嗎？”
- 戰術判斷，例如：
- “我們應該合併這個分支嗎？”
- “我們應該部署到這個環境嗎？”
- “我們應該發起/銷燬一個環境嗎？”
- “這個功能正常嗎？
- “應用程序安全嗎？”
- “我們搞出了新的錯誤嗎？”
流水線是戰術層面的
我認爲流水線很適合作出戰術性的日常判斷和行動，而人類更適合戰略層面的工作。如果有人找到一種方法讓流水線來決定他們的下一個產品應該是什麼，不需要人類來簽字許可，那肯定皆大歡喜。但我認爲這種事情是不可能用決策算法來處理的。
戰術層面的事務通常更適合用機器來檢查：這類事務往往會重複執行某些操作，不會跳過其中的步驟；還會驗證一系列清單；收集和分析數據以獲取特定數值等。
這些決定與以下內容有關：
- 我們代碼的健康度和功能
- 環境
- 質量
- 安全
- 合規
- 運營
- 部署
…… 以及與軟件開發生命週期相關的其他事項。
如果讓流水線取代人類做出這些判斷（我們在傳統的敏捷和瀑布組織中都是讓人來做決定），我們可以獲得以下好處：
- 做出更快的決策/判斷
- 更可靠的重複決策
- 減輕壓力
- 實現真正的持續交付
更快的判斷
流水線之所以能比人類更快做出決定，有兩大原因：
- 在具體的事實層面，計算機的計算速度比人類快
- 當計算機要決定是否合併分支或啓用環境或部署應用時，它不會感到壓力或焦慮或惴惴不安的感覺
更可靠的重複判斷
流水線在重複事務上作出的決策更加可靠，也有兩大原因：
- 計算機非常適合瀏覽一長串事物並驗證每一件事情，而不會忘記某個項目，或每次作出不一樣的檢查
- 計算機不會感到無聊、煩惱或者因爲某項檢查連續十次失敗而感到沮喪，或者抱怨爲什麼沒有人爲此負責，抑或是冒出來一些念頭：“快拉倒吧，我要回家看孩子去，再也不想管這個了。“
減輕壓力和焦慮
在一家有着漫長而艱苦的人工測試流程的公司工作壓力是很大的，尤其是新版本發佈之前開特別會議的時候，管理團隊盯着測試團隊的頭頭，問他們：“這個版本準備好發佈了嗎？”——壓力山大！
測試團隊的領導是很好的心理學研究對象。想象一下必須你來簽字決定新版本是否投入生產——這時候你就是大家的代碼與全世界之間的最後一道防線，你會是什麼感受？
實現真正的持續交付
最後我們來看它的核心優勢。
持續交付是一種軟件工程方法，團隊要在較短的週期內生產軟件，確保軟件可以隨時可靠地發佈。
我認爲，成功實現持續交付的關鍵是消除戰術決策鏈中的人爲瓶頸，使流水線幾乎能夠自主地決策並推動代碼前進，直到生產發佈環節；沒有人類的恐懼和懷疑這些絆腳石後，我們就能更快獲得關於我們代碼表現的反饋。
教會流水線自行驅動工作
爲了能夠完全信任流水線，使我們可以依賴它的決策，我們需要教會軟件流水線在無人蔘與的前提下自行做出戰術判斷。每當我們的流水線學會了一項新的戰術決策，我們就消除了一項人爲瓶頸，在實現真正的持續交付的道路上更進一步。
所謂教育，是說我們要在流水線中添加自動化步驟、腳本和質量關卡，根據我們關心的各種結果或指標決定一系列步驟是失敗還是通過。具體來說可以有下面幾種形式：
- 基於自動測試的結果判定失敗/通過
- 基於正在測量的特定度量標準判定失敗/通過（例如代碼覆蓋率急劇下降）
- 基於子流水線或並行流水線的結果判定失敗/通過
- 基於日誌文件判定失敗/通過
- （如果你有更多想法，請發送電子郵件至[rooe at osherove.com]）
像Netflix、谷歌和亞馬遜這樣的組織就可以算是流水線驅動的；他們讓團隊中的流水線做出日常戰術判斷，並自動執行相關的操作，無需人力干預（參見“在Netflix和Waze使用Spinnaker實現大規模持續交付（Cloud Next '18）） 。
他們不再讓某人每分每秒盯着戰術工作並作出決策，而是讓流水線推動工作進程。然後人們負責教導流水線作出自動判斷和制定戰術決策，從而打破了許多戰術流程中的人爲瓶頸。
流水線驅動流如何改變日常工作
傳統上（非流水線驅動），流水線會“詢問”或“通知”人們是否一切正常（測試通過、編譯通過等）。然後，人們必須決定是否可以開始下一步，然後點擊按鈕來觸發獨立的流水線或作業。
如圖：傳統的敏捷流水線被知識島和人工決策分隔開來，由人來決定是否在SDLC流程中觸發下一條流水線。
在流水線驅動的流程中人們完全信任流水線，這樣如果一切正常就會自動觸發下一步。這裏的假設是流水線知道如何正確判斷某些事務是否正常，所以只需繼續下一個動作，不用等待人類去觸發。
在上圖中，你可以看到組織中的各種知識島負責在自動化流水線中嵌入決策邏輯。作爲流水線執行的一部分，決策會自動執行，無需等待“外部”人們的批准或手動操作。
新世界需要新技能
我們在嘗試採用敏捷流程時經常會遇到的四大知識島，如下圖所示；每個島都有一項與他人相關的有價值的技能，需要其他島上的人們學習。
- 開發技能：流水線是自動運行的代碼片段，因此與流水線相關的一項主要技能就是學習基本的編碼技術。如果你不會寫任何代碼，連簡單的完全自動化基礎架構的腳本都不會寫，那麼你就無法爲流水線做出任何貢獻，也無法瞭解它的工作機制及故障原因。。
- 測試技能：所有流水線都是一個巨大的測試項目。結果要麼是紅燈要麼是綠燈。它是由一系列“步驟”組成的——每一步都是對其中的內容和步驟本身的一種測試。如果某一步失敗了，那麼流水線也會失敗（或者應該失敗）。向流水線作貢獻就是在其中添加步驟或測試，而且這些測試/步驟是用代碼編寫的。因此你不僅需要知道怎樣寫代碼，還需要知道如何編寫可以在流水線中運行的測試。你需要有一種測試心態——要能幫助設計並創建自動測試，而不是手動檢查某些內容。
- 運營技能：大中型公司的流水線傳統上屬於運營領域和開發人員。但是，如果我們希望人們能爲流水線貢獻測試，則他們需要知道流水線的基本工作機制，知道如何理解它們的輸出、如何配置（添加和刪除它們的步驟）、如何訪問以及如何運行這些流水線。
- 安全技能：安全性是一組技能和思維方式，涉及代碼、基礎架構、配置和部署等方方面面。這意味着傳統上生活在自己的孤島中的安全人員必須開始分享他們的安全知識，因爲在這個全新的世界中每個人都擁有更多的權力，需要承擔更多責任。我們允許所有人觸碰流水線並編寫在其中運行的代碼。所以要教他們在所有事務上都要考慮安全性。
我們還可以繼續擴展這個列表，添加更多技能，但篇幅所限這裏就不提了。我會在我的博客上深入探討這些內容。
如圖：在每個知識島上我都指出了（用彩色圓點）來自其他島的相關技能，也是各個島上的人們需要學習改進的技能。
總結：這對你來說意味着什麼？
無論你喜不喜歡，流水線都將越來越普及。組織爲了增強自身的競爭力，對流水線驅動的需求也會增加。
這意味着知識共享、自動化能力、測試能力和編寫代碼的能力會在你的工作中發揮重要作用，而缺乏這些技能會影響你在業內的表現和潛力。
許多組織都在試圖實現持續集成或持續交付，但他們都遇到了障礙：流水線之間存在太多人爲瓶頸，讓人決定軟件流程能否繼續到下一步（部署，測試等）會大大降低效率。
如果能教會流水線做出更好的決策，取代人類作出判斷，我們就能讓流水線在生產流程中自動工作，通過它們（如果它們連續運行）創建真正的連續交付機制。
如果流水線失敗——取消新版部署。如果它通過——我們就部署新版本。完全不用人操心。
今天只有少數公司，諸如像亞馬遜、Netflix、谷歌等組織完全實現了這一願景。我認爲他們之所以能實現現在這種規模和速度，部分原因正在於此；他們將人類移出戰術決策過程，人類只負責教會流水線來完成他們的工作。
你可以在Roy的博客或Twitter上閱讀有關流水線驅動組織的更多內容。
作者介紹
Roy Osherove是即將出版的新書《流水線驅動》的作者。他還是《彈性領導：發展自組織團隊》和《單元測試藝術》的作者。Osherove曾在一些世界上最大的公司從事軟件開發方面的許多工作。如今，他爲全球各地的企業擔任自由顧問、培訓師和教練，工作內容包括測試驅動開發、敏捷技術領導、持續交付以及基於流水線的組織的有效指標等。在這裏可以找到更多關於他的信息。
原文鏈接：
The Pipeline Driven Organization - Enabling True Continuous Delivery