2009年底，比利時根特舉辦了第一屆DevOpsDays。Chris-Read作為嘉賓之一，代表ThoughtWorks出席了這次活動并帶來名為“持續集成，流水線和部署”的演講。ThoughtWorks作為DevOps運動最早的見證者和奠基人，并沒有意識到這個周末聚會將在接下來10年給全球IT行業帶來深遠影響。
1個月后，ThoughtWorks發布了第一期的技術雷達。作為一個新興的名詞，DevOps還沒有成熟到讓令人矚目的階段。然而，即便DevOps還沒有被納入技術雷達，但與之相關的早期實踐和工具都已出現。在接下來的十年中，DevOps已經成為每期技術雷達不可或缺的一部分。從這個角度上說，技術雷達就是DevOps發展的見證者。
DevOps和技術雷達都將迎來自己的不愁之年。作為IT行業技術的先行指標，技術雷達上面的技術平均領先行業3至5年。也就是說，出現在技術雷達采納和試用區域的技術，在3-5年后大概率將成為業界主流。
作為DevOps和技術雷達的粉絲，我想從技術雷達的角度總結DevOps的發展歷程。該系列文章共分為三篇，分別是：
- DevOps和持續交付
- 基礎設施即代碼和云計算
- 容器技術和微服務
本文為“DevOps和技術雷達相伴十年”系列文章第一篇：DevOps和持續交付。
DevOps
雖然持續集成、構建流水線和持續部署從技術雷達創刊號就存在。但DevOps作為一個正式條目進入技術雷達的評估象限是在2010年8月的第三期技術雷達。那時，對DevOps的描述是這樣的：
“DevOps是一個新的運動，在尋找可以滿足業務需要的快速交付的軟件和穩定的生產環境。它擁有兩個目標：首先，讓開發和運維的合作更加緊密。其次，在運維流程中應用敏捷實踐（協作，自動化，簡單化）來處理初始化虛擬機，變更管理和生產環境監控。它包含文化、流程和工具，全部用于支持更好的溝通，快速的交付和反饋以及可預測的產出上。”
半年后，DevOps運動所引發的影響越來越大。2011年1月，DevOps作為條目進入了“試用”區域。這意味著至少ThoughtWorks內部已經全然接受DevOps。在這一期的技術雷達中，對DevOps的描述做了一些調整：
DevOps運動持續讓人們關注經常斷裂的開發和運維關系。DevOps提升了開發和運維的合作以及共同的責任。DevOps在運維過程中應用敏捷實踐,初始化虛擬機，變更管理和生產環境監控并為開發階段引入了近似生產環境的思維，工具和環境。DevOps是對一個想對應用發布到生產環境實施持續交付的關鍵基礎。
就像本文開頭說的，作為IT行業技術的先行指標，技術雷達一直都做得不錯，出現在技術雷達上的技術平均領先行業3至5年。2011年6月，DevOps正式進入技術雷達的采納象限，這就意味著DevOps最晚在未來的5年中會成為業界的主流。
2012年3月，技術雷達徹底更新了之前對DevOps的描述：
改進開發和IT運營的交互和關系讓有效的交付生產系統更加穩定和可維護。創建一個DevOps文化需要關注團隊組織，工作實踐，匯報線和激勵機制。它會帶來對更加快速和安全的交付的共同責任。我們推薦采用DevOps是因為是看不到任何無法帶來正面收益的情況。
這也就是說，在2012年，全球的ThoughtWorker們就已經認為在未來DevOps一定會帶來益處。而5年后的2017年，北京才舉辦第一屆DevOpsDays，標志了DevOps在中國發展的元年。
最初，社區想讓運維敏捷化，但DevOps走出了另外一條路。
持續交付
我個人一直覺得，如果持續交付在2009年Velocity大會上出現，DevOps很有可能不會出現。
當JezHumble于2010年第一次在DevOpsDays介紹持續交付的概念之后，持續交付就成為了DevOps的核心實踐，直到現在。然而，持續交付在一年后才進入技術雷達，且第一次出現在技術雷達上的時候就直接落入了“采納環”，技術雷達是這么描述持續交付的：
如果你想知道“敏捷之后會發生什么”,你應該關注持續交付。雖然您的開發流程可能已完全優化,但您的組織可能需要數周或數月才能將單個更改轉化為生產。持續交付的重點是最大限度地實現自動化,包括作為代碼的基礎架構、環境管理和部署自動化,以確保您的系統始終為生產做好準備。它是關于收緊你的反饋循環,而不是推遲任何東西,直到結束。持續交付與持續部署不同,這意味著將每個更改部署到生產環境。連續持續交付不是牛仔表演。它讓您對生產環境負責。企業可以選擇部署的內容和時間。如果你認為自己已經確定了敏捷開發的目標,但沒有考慮如何實現持續交付,你真的還沒有開始。
雖然DevOps比持續交付提前半年進入了技術雷達，但持續交付這一理念的各個組成部分早在技術雷達的創刊之前就存在了。
在2010年1月的技術雷達創刊號上，“構建流水線”（BuildPipeline）的概念就已經處于技術雷達的“采納”環內。在持續交付出現之前，構建流水線已經連續4期穩坐在技術雷達的“采納”環內。我們現在可以把構建流水線看做是“持續集成”的一種擴展實踐，當時它已經被廣泛的運用到了各種開發項目上。
與此同時，“持續部署”（ContinuousDeployement）作為“軟件交付最后一公里”的實踐，由于風險始終處于“評估”和“試用”階段。直到和持續交付同時出現在技術雷達上。彼時，構建流水線、持續部署和持續交付是三個不同的實踐。你可以簡單的認為“構建流水線+持續部署=持續交付”，然而，持續交付所涉及的內容卻不止涵蓋技術層面。《持續交付》一書的作者JezHumble在其博客“持續交付vs持續部署”中詳細介紹了其中的區別：
首先，嚴格來說，部署并不暗示發布，你可以持續的部署到UAT環境。讓持續部署變得特別的是把每一個改動都通過自動化測試（或者簡短的QA門禁）部署到生產環境。持續不是發布每一個良好構建給用戶。這么說來，更準確的叫法應該是“持續發布”。
其次，持續交付是關于把發布計劃交給業務，并不是交給IT來決策。實現持續交付意味著確定你的軟件在整個生命周期內都是可以部署到生產環境上的。任何一個構建都有機會通過自動化的過程被發布給用戶。
但是，這并不是說都把每次成功的構建交付給用戶是一個好主意。特別是，有些嵌入式產品包括了軟件和硬件的變更。在這些情況下，少次變更的感受可能會更好。關鍵在于，這些發布都是業務驅動的。
2011年6月份的技術雷達中，持續交付和DevOps同時出現在了的“采納”象限。嚴格的說，DevOps并不是一項技術、也不是一種實踐，它是圍繞著一個理念的運動。由于DevOps缺乏官方的定義，所以DevOps可以是任何東西。但持續交付不同，持續交付通過《持續交付》這本書傳播了一套完整和系統的方法論。這套系統的方法論和DevOps的理念不謀而合，因此，在DevOps社區內被廣泛應用。直至今日，持續交付與否仍然是一個組織是否具備DevOps能力的一項關鍵能力。
換句話說，持續交付可以沒有DevOps，但DevOps不能沒有持續交付。
技術雷達判斷的沒錯，《持續交付》不光影響了DevOps，也影響了其它軟件領域。隨著持續交付的盛行，特別是流水線的概念深入人心，在不同領域誕生了不同的持續交付技術。例如：基礎設施流水線，鏡像構建流水線，移動設備的持續交付。
持續交付和DevOps中的反模式
由于DevOps缺乏一個官方標準，因此對DevOps的理解和實踐就會有所偏頗。在知道什么是“好的實踐”的過程中，我們也需要知道那些“不好的實踐”，例如CI劇場（CITheatre）：
長期以來，我們一直倡導持續集成(CI)，我們是構建CI服務器程序以自動構建簽入項目的先驅。使用得當的情況下，這些程序作為開發人員每天承諾的共享項目主線上的守護進程運行。Ci服務器構建項目并運行全面測試，以確保整個軟件系統集成并處于始終可發布的狀態，從而滿足持續交付的原則。遺憾的是，許多開發人員只是設置了一個CI服務器，錯誤地認為他們正在“做CI”，而實際上他們錯過了所有的好處。
常見的故障模式包括:對共享主干運行CI,但很少提交。因此集成并不是真正連續的;運行測試覆蓋率較差的生成;允許構建長時間保持紅色卻不修復;或對特征分支運行CI,從而導致連續隔離。隨后的"CI劇場"可能會讓人感覺很好,但卻會讓任何可信的CI失敗。
此外，很多人在理解持續集成（CI）的時候，就僅僅以為是安裝一個CI軟件（例如Jenkins）自動化打包。而忽視了整個CI的九項關鍵原則：
- 維護單一代碼庫
- 自動化構建
- 讓構建可以自測試
- 所有提交都要在一臺持續集成機器上進行構建
- 讓構建保持快速
- 在類生產環境上進行測試
- 讓任何人都可以輕松的取得最新的可執行版本
- 每個人都可以看到發生了什么事情
- 自動化部署
關于如何正確的做持續集成，可以參考ThoughtWorks官方的持續集成介紹，進一步了解詳情可以查看MartinFowler的原文。
此外，隨著持續集成這項實踐被廣泛采納。大型的項目也開始遷移到持續集成服務器上，就會導致“為所有團隊構造單一CI實例”：
我們不得不再次告誡，不要為所有團隊創建一個CI實例。雖然在理論上整合和集中持續集成(CI)基礎結構是一個不錯的主意，但實際上，我們在這個空間的工具和產品中沒有看到足夠的成熟度來實現所需的結果。軟件交付團隊必須定期使用集中式CI產品，這些團隊會根據中央團隊執行次要配置任務或解決共享基礎結構和工具中的問題而長時間的延遲。在這一階段，我們繼續建議各組織將其集中投資限于建立模式、準則和支持交付團隊運行自己的CI基礎設施。
然而，隨著CI不斷膨脹使得CI管理員不得不拆分流水線和自動化測試，以便使得大型、緩慢的自動化測試能夠獨立運行。一個代碼庫被拆成多個代碼庫。一條流水線被拆成多條流水線。既然能夠獨立測試、必然能夠獨立部署。于是，慢慢的也就產生了微服務的概念。關于微服務，我們將在以后講。
下面是持續交付和DevOps相關條目的發展歷程一覽圖。實線為同一條目的變化，虛線為影響的相關條目：
DevOps 和持續交付的理念在10年中不斷發酵，影響了之后工具和技術的發展，技術雷達捕捉到了這些全球的趨勢。讓我們從最早開始改變的數據中心和云計算看看 DevOps 帶來的影響。
敬請期待第二篇《從技術雷達看DevOps的十年——基礎設施即代碼和云計算》
相關條目：持續交付，構建流水線，持續部署，基礎設施流水線，鏡像構建流水線，移動設備的持續交付，Spinnaker。
文/ThoughtWorks顧宇
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見
