一次又一次，我們不斷聽說眾多企業客戶利用DevOps機制實現快速交付。各大廠商每天也在不斷宣揚著利用此類部署獲得成功的實際案例，并鼓吹稱借此能夠實現每天十套、五十套甚至上百套業務線的部署工作。而在LinkedIn、Netflix、Etsy、Facebook以及其它成熟企業當中，這一數字甚至能夠突破上千套。不過，這一切到底意思著什么?

IT領導者最喜歡談論這些看起來令人振奮的數字，而且往往會將快速交付作為對話的主要關注焦點。然而這類軟件交付方式到底是否穩定可靠?其中哪些部署方案能夠切實取得成功?整個部署流程又由哪些步驟來構成?

這些問題往往最終造成分析癱瘓，但卻給不出任何一種有實際意義的結論。事實上，企業最常見的反往往是“在我們公司，我們沒辦法實現某種目標，因為……”我們知道這種說法根本站不住腳。那些以瀑布式機制通過單一部署流程按月或者按季度進行產品交付的傳統企業完全能夠與其它團隊一樣，成功過渡至快速部署并由此擁有理想的交付能力。

那么我們要如何才能以軟件交付為起點享受此類成功果實?世界上并不存在萬靈藥或者一步到位的解決方案，但大家卻能夠通過方法論指導自身達成快速交付目標。下面讓我們一同了解起步階段的必要任務。

基本原則

讓我們通過以下這些關鍵性原則來照亮通往光明彼岸的道路。它們分別是：

接受失敗

分析失敗原因，但不苛責任何相關人員

在了解理由后快速修正失敗因素

永遠保持迭代

簡而言之，我們的目標應該是快速部署、快速失敗、快速學習而后快速改進。這是一項永無止境的任務，而且我們也需要始終以這樣的思路看待整個流程。相信大家都曾經經歷過，一個項目在啟動過程中會將這些原則考量在內，但隨著項目的終結、這一切最佳實踐也隨之消散。除非將持續改進作為核心訴求傳遞給交付對象，否則任何一種努力都有可能隨著時間的推移而最終失效。

在將上述原則牢記在心之后，我們接著邁出下一步。

軟件是怎樣被開發出來的?

我們的第一站有時候并不從屬于交付組織，而體現在開發組織當中。這也就是“移情”思維的作用所在，即站在對方的角度看待問題。DevOps概念也恰恰是針對這一焦點; 我們首先需要確保負責交付功能的開發人員具備獲得成功的一切要素。

軟件到底是如何被開發出來的?這一切對于生產流程究竟意味著什么?大家不妨向自己提出以下問題：代碼是如何被引入源代碼樹的?可接受代碼應該具備哪些特點?(舉例來說，是否存在代碼格式指南或者必要測試等支持機制。)

一旦弄清了以上問題，接下來的關鍵就是將代碼進行改善，從而將其推向交付的下一個階段。但這往往正是瓶頸的出現之處：雖然過去的歷史案例能夠起到有效的指導作用，從而以引入檢查點的方式來嘗試并改進產品質量，但這些檢查點通常以人為方式驅動——很明顯，人為方式總是有著種種自身缺陷。

最重要的一點是分清楚代碼交付或者功能交付與軟件本身交付之間的區別所在。雖然二者對于下一階段的工作來講都是非常重要的前提性條件，但雙方的職責往往各有所專。在整體系統當中，我們的需求始終是一致的：尋求機會，通過拆分流程步驟的方式降低摩擦(即那些由傳統機制帶來的毫無價值的非必要因素)或者利用自動化方式推進整個周期。

考慮到這一點，開發團隊與運營團隊之間的對話將帶來持久的啟發性成效，因為在充分交流之后、雙方都將清醒地意識到導致流程緩慢的原因所在。請大家繼續集中精神，讓我們繼續進入下一個議題。

接下來的幾個問題請務必牢牢記在心中：

哪些員工能夠編寫軟件?是否每位員工都有能力編寫軟件?

在學習軟件編寫的過程中，是否存在著明顯的入門壁壘?

將工作代碼向同事展示到底有多困難?

同事運行我們的展示代碼到底有多困難?

哪些員工能夠部署這些軟件?

在學習部署軟件的過程中，是否存在著明顯的入門壁壘?

我們需要在哪里進行任務分配?

我們需要在哪里討論新功能的引入?

以“高檔位”推動流程加速

到這一步，大家可能已經擁有了一套軟件方案當中需要改進的各項條目的明確列表。但是，我們該把關注重點放在哪里?當下的默認思路是先理清發布機制，而后再嘗試與外部團隊進行良好協作。然而這其實是最不明智的作法，因為它最終將導致開發與運營團隊之間產生無法逾越的鴻溝。因此對于大家來說，最好的判斷也許是將對接放在第一位。

我們的第一步工作應當集中在兩大主要目標身上。第一是將自身嵌入到開發工作流程當中……通過現有流程從開發任務內提取項目元素，并提出針對性的主張。這些主張將成為我們的“第一個追蹤對象”，并幫助我們理解哪些變更能夠實際起效、而哪些不能。此外，它們還能夠帶來有價值且中肯的反饋意見，這往往是其他對項目進度并不關注——或者說其主要精力集中在了其它工作上——的同事所無法提供的。總而言之，從小處著手幾乎是必要且最理想的處理方式。

在這一階段，DevOps會提出大量的所謂“移情”性觀點。無論是在改善產品方面投入怎樣的努力，一旦摩擦元素開始在開發者的日常工作當中出現，那么變更帶來真正成功的可能性也將變得愈發低下。舉例來說：對大家而言，對底層交互平臺的變更也許能顯著改善溝通效果，但如果這種作法破壞了現有交付通道，那么結交新朋友的幾率很可能反而有所下降。

將自己的主張整理成開發報告，并提交給所在團隊——反之亦然——最后將其納入整個執行流程。另外，也不要忘記始終遵循前面提到過的基本原則……快速部署、快速失敗、快速學習與快速改進。盡快修復易于處理的流程漏洞。再有，高度關注任何給定時間段內引入的變量數量，不要害怕進行變更，但同時始終保持變更的一致性并加以衡量。只要能夠長期堅持做到以上幾點，我們的整個交付流程將得到理想的調整與改進。

與之同理，通過這一流程建立起真正的項目成果。早期的成功能夠確保開發人員得以通過最低限度的努力運行任意代碼版本(無論是git檢查版本還是其它主要版本)。

這使我能夠利用來自其他同事的代碼測試自己的開發成果修復效果、確認漏洞以及其它類似的工作。擁有了運行任意代碼的能力，我們就能夠合作加快代碼的開發流程、降低開發末期可能遭遇的問題數量，這意味著大部分難題在流程早期就已經得到了解決。這樣的效果對于階段性交付環境——很可能是本地開發環境——而言非常重要。不過除此之外，構建起一套允許開發人員以小型獨立任務方式運行代碼的平臺同樣能夠有效支撐起后續的生產交付流程。

一旦大家發現流程及開發工作當中出現了失誤，請千萬牢記一點：針對該失誤進行分析與修復，但不要因此則苛責任何人。首先，這類問題的項目早期階段會大量出現，相信這也是我們每個人的共識。John Allspaw在他的文章當中談到了這一點，并將激勵作為最主要的思維立足點：

“因為工程師們在心態上往往認為自己針對特定故障的機制、原理以及操作方式給出理解所必需的細節信息的作法不會受到鼓勵、甚至可能因此而遭受指責。這種關于 問題發生原因的認知缺失往往不斷重復出現。而如果后期負責相關工作的工程技術人員有所變動，那么未來還將有更多故障不斷涌現。”

另一個經常被忽視的問題是這些解決方案的具體實現手段。此類修復流程不應該由某一個人或者自上而下的方式予以驅動。相反，團隊中的所有成員必須都能夠成為解決方案的組成部分。時間與鼓勵將在長期工作當中起到非常積極的促進作用。

最后，部署。項目的最終意義就是部署代碼。到這一步工作已經基本結束，接下來要做的就是專注于開發與運營團隊之間的相互作用，不過雙方也需要在一部分任務當中共同協作。除非大家能夠以毫無瑕疵的方式完成日常部署，否則彼此溝通將貫穿整個部署流程。在每天的工作當中，我們都應該嘗試一次代碼部署——無論我們是否能夠預見到其實際效果。另外，每天找出一到兩個問題并加以修復：包括流程中的故障或者手動階段中的問題。重復這些任務，直到我們能夠以最低命令數量完成日常部署目標(最好是一行命令就搞定)。

前方的道路還很崎嶇，請做好心理準備!

在不斷推進的過程中，我們將反復面對兩大關鍵性主題。第一就是通過溝通解決問題。隨著時間的推移，部署工作的推進速度將不斷加快或者愈發精簡，但即使是最出色的團隊也需要想辦法克服由溝通障礙所帶來的挑戰。

第二則是解決相關工具的使用能力問題。一旦工程師們開始引入實現過程所必需的工具，一切人為及流程因素都將居于次要地位——或者說以工具為核心加以適應。這往往是道難以克服的關隘，因此此類工具要求軟件交付相關組織之內的各位成員真正參與到溝通當中。

考慮到這一點，我向大家推薦兩款能夠切實幫助各位突破阻礙的工具：CahtOps與Workflow。二者都屬于非常出色的解決方案，值得我們用專門的章節來加以闡述。不過受限于篇幅，我們在這里一言以蔽之：它們是軟件交付工作中必不可少的組成元素。

“ChatOps能夠將我們已經完成的工作以背景信息的方式添加到對話中來。” – James Fryman

“ Workflow所使用的可讀機器腳本語言絕不受限于對話范疇。它已經成為在實時系統當中以動態方式創建、上傳并更新工作流程的必要因素，并應當被作為“基礎設施即代碼”予以重視。” – Dmitri Zimine

請記住：問題的關鍵并不限于單一工具。這些工具只是達成目標的一種手段。人與流程需要成為對話中的核心組成部分。ChatOps能夠通過溝通及合作來創造并推動開發進程。Workflow則從基礎設施流程角度出發實現整體協作。二者都應該成為軟件交付工作中的必備元素。

內容概述

為了獲得成功，作為技術人員的我們需要了解自己的組織當中發生了什么、技術手段如何幫助交付流程達到預期效果，而技術元素又是如何被部署并被哪些用戶使用的。如果沒有清晰的理解，我們將陷入遇到問題就引入工具，但工具的出現反而增加了問題復雜性的惡性循環。在這種情況下，工具往往會成為流程推進的瓶頸或者徹底淪為花瓶——因為人們根本就不打算真正加以使用。在快速發展的今天，精益化業務流程不會允許我們把時間浪費在故障身上。

您是否了解所在團隊是如何交付軟件并在流程中實現協作的?您的團隊與服務交付對象之間是否存在著緊密的反饋通道?您是否有能力實現快速行動，甚至以更快速度修復問題?

時至今日，軟件交付速度已經被廣泛視為市場競爭中差異性優勢的典型代表。通往這一目標的道路既不平坦也不順暢，但一旦實現、我們的組織也就同時做好了邁入下一個快速成長階段的準備。