快速指南：在DevOps中實現持續交付

【編者的話】時至今日，以幾乎相同的步調實現開發與交付已經成爲一種必需。本份快速指南將幫助你們弄瞭解持續交付概念中的那些「良方」與「毒藥」。

【燒腦式Kubernetes實戰訓練營】本次培訓理論結合實踐，主要包括：Kubernetes架構和資源調度原理、Kubernetes DNS與服務發現、基於Kubernetes和Jenkins的持續部署方案 、Kubernetes網絡部署實踐、監控、日誌、Kubernetes與雲原生應用、在CentOS中部署Kubernetes集羣、Kubernetes中的容器設計模式、開發Kubernetes原生應用步驟介紹等。

開發人員老是面臨着軟件發佈規模與速度層面的種種壓力，而這亦促使其採用各種新型概念和工具。可是，使人困惑的術語混淆了真正的技術和商業利益，特別是考慮到供應商也擁有本身的傾向與訴求。若是您須要的是真正的技術手段而非營銷口號，你們每每會發現本身很難爲持續構建與交付的實現找到最佳方法。本文將爲你們帶來與持續交付相關的基礎知識，但願可以爲各位帶來一點啓示。

首先，如下術語適用於同一輩子產流程的不一樣部分，而各個部分的自動化程度皆不盡相同。

• **持續集成（Continuous integration）**是指頻繁將代碼合併至中央儲存庫中。「頻繁」一般具體指一天屢次。每次合併操做都會觸發一個自動化的「構建與測試」實例，這一過程也會被稱爲持續構建。可是不管具體表達如何，持續集成和持續構建都沒法直接實現交付和部署方面的工做——其只負責代碼層面的管理，而不涉及其它具體事務。

• **持續交付（Continuous delivery）**是指軟件交付過程當中的自動化機制，其中包括一部分須要開發人員親自動手的操做。一般來說，開發人員都會容許和啓用自動部署，不過同時也會配合其餘一些手動的步驟。

• **持續部署（Continuous deployment）**是指不須要開發人員以手動方式操做的持續交付機制。整個流程皆自動實現，而不須要人爲參與。

Marko Anastasov在一篇博文中解釋稱，利用持續部署，「開發人員的工做一般集中在檢查同事們提交的合併請求，並在將其合併到主分支上後即宣告完成。」持續集成/持續部署服務在這裏接管後續工做，包括運行一切測試案例並將代碼部署到生產環境中，然後通知相關團隊每個重要事件的對應結果。

然而，僅僅瞭解術語和它們的定義並不能幫助你們肯定應在什麼時候、何地對其加以運用——畢竟每種技術都擁有着本身的優點與劣勢。

固然，若是市場能像對待DevOps同樣清楚地區分這些概念、工具及其對應受衆，天然能夠帶來完美的成效。然而……

「DevOps是一種概念，一個想法，一類生活哲學。」軟件交付自動化廠商XebiaLabs公司首席營銷官Gottfried Sehringer指出。「這並不是一種特定工序或者工具集，也不是一種技術。」

遺憾的是，行業裏的術語不多配有簡單明瞭的表述，也沒有提示可以告訴人們如何以及什麼時候使用這些技術。所以，這份指南旨在幫助你們瞭解什麼時候適合使用哪一種技術。

根據你對速度的需求來選擇加速方案

等等，速度難道不是全部軟件開發的關鍵嗎？現現在，公司一般都會要求開發人員天天，每週或是每個月進行軟件更新或者添加新的功能。這在過去，甚至在敏捷開發時代下都是聞所未聞的嚴苛要求。

不止於此，一些公司還會追求更快的軟件更新速度。Sehringer說：「若是你在亞馬遜工做，那極可能每幾秒鐘就須要進行一次更新。」

不論你是軟件漏洞的行家，或是開發人員又或是運維專家，當必須快速完成構建與發佈任務時，你們該如何提供高質量且「不破壞任何既有成果」的代碼呢？面對這樣的問題，每一個人都有本身的妙招。「敏捷開發」，「持續構建」和「持續集成」則是其中呼聲最高的三種方案。

下面讓咱們對其進行歸納說明。

軟件服務供應商Nexient公司資深交付主管Nate Berent-Spillson指出，「你能夠把持續性當作是‘自動化’。它下降了開發和部署的成本與時間。」

那爲何不直接使用自動化做爲專業表達？

自動化概念的加入、持續構建、持續交付以及任何與持續性相關的因素，都屬於DevOps的核心範疇，而咱們其實陷入了文字表述的誤區。下面，咱們將帶你們共同理清思路。

自動化DevOps的三要素

持續構建的本質在於「經過小步驟進行構建。」每一個小的步驟都是爲了把軟件以持續性方式集成到生產環境中這一目標而服務。

儘管部分實踐者會對「持續集成」概念做出進一步細分，但「持續集成」這一標籤仍經常被指向同一類事物。持續構建屬於持續集成的組成部分：在持續構建的過程當中，開發者只需編寫代碼，並將其與倉庫中現有的代碼合併，以後就可讓自動化來接管構建和測試合併後的代碼。這樣開發者將沒必要浪費時間在手動編譯和測試上，而是把更多時間投入到代碼編寫與創新實現身上。

可是，僅僅利用部分自動化工具並不意味着可以提高整個發佈流程的速度表現。畢竟代碼自己尚未部署完成——而部署工做可能須要手動操做，也可能由於開發人員忙不過來而被推遲。

做爲OutSystems（面向企業的移動和網頁應用的快速交付平臺）公司的首席技術佈道者，Dan Juengst解釋說：「隨着持續集成的運用，組織可以從以笨重的總體式應用（monolithic application）爲核心的思惟模式升級到一種可以支持並鼓勵輕量化且高頻度軟件更新的方案。」

然而，在更大規模的持續集成過程當中，與其說持續集成是一個獨立的步驟，不如將它當作是一種並行的步驟。InfoZen公司首席轉型官Susan W.Sparks說：「不一樣於僅僅提供了一種可持續且低風險代碼部署方案的持續交付機制，持續構建在持續集成當中負責按期合併新代碼並實施構建。」

正如Sparks所言：「經過持續集成，你也能夠實現持續交付。」固然，前提條件是你們的代碼具有可部署性。

另外，你們還須要把創新團隊放在首位。前雅虎首席技術官，現任Cybic首席技術官的Mike Kail說：「將DevOps落地的第一步一般就是採用持續集成。這爲開發人員提供了更加協調的環境，有利於提升代碼質量。」

什麼時候使用持續集成vs.應用程序的自動化發佈

那麼持續集成是否就是應用的自動化發佈（ARA）——這兩種稱爲是否表明着同一事物？答案是否認的，正如Sparks所言：「它們是同一框架下的兩種不一樣組件。」

持續集成的運用集中體如今使用公共源代碼庫(如GitHub)的應用開發人員上。Sparks說，每當開發人員更新軟件時，他們的代碼都將被從新整合到整個應用中。換句話說，持續集成工具檢查全部的源代碼，構建全部成果(例如編譯軟件)，運行全部的單元測試，同時當即做出結果反饋。

另外一方面，應用的自動化發佈是指對集成後的代碼進行打包，並在開發結束後將代碼自動轉移。

Sparks說:「舉個例子，開發始於代碼。當實現了全部功能並經過了全部測試以後，你就能夠利用應用程序自動化發佈來將代碼包移動到下一個環境，例如測試環境。」

從另外一個角度來看，就像Sehringer說的：「持續集成是內容，而應用的自動化發佈則是運用工具的過程，兩者屬於同一事物的不一樣側面。」

沖洗。重複、重複、重複、重複（DevOps中的自動化）

自動化機制擁有理想的投資回報。Sehringer指出：「若是在前期製做階段可以確保產品的萬無一失，那你就能當即把它推向生產而不破壞任何原有成果，以後只要重複這一過程就能夠了。」

換句話說，您能夠經過結構化、可重複的自動化方式來實現全部的交付步驟，從而下降風險並提升發佈和更新的速度。

「在最理想的狀況下，你只需按下一個按鈕，就能夠作到每幾秒鐘就進行一次發佈。」Sehringer說。「但現實世界沒那麼理想化，仍是須要人工插手來把整個流程對接起來。」

公司可能須要法務部門的批准才能對應用作修改。Sehringer指出：「一些受到嚴格監管的公司甚至須要額外的手段來確保合規性。所以，瞭解瓶頸的具體所在是很重要的。」ARA軟件應該提升效率，並確保應用可以按時發佈或更新。

Sehringer 還說：「開發人員對持續集成更爲熟悉，而應用的自動化發佈則屬於較新的概念，也所以致使理解程度廣泛不高。」

整合，然後加以嘗試

首先，要了解你的承諾、風險在哪裏以及目標是什麼。

Berent-Spillson表示：「持續構建、持續集成和持續交付只能算是基本底限，持續部署纔是更爲深刻的步驟。」

他補充稱:「利用持續部署，您能夠承諾在不須要人工參與的狀況下來部署每一行新代碼，而再也不以人爲方式一次性將代碼發佈出去。當新代碼提交到存儲庫時，其將自動接受構建、集成、測試和暫存（stage）。其中的核心變在於對主線開發做出的承諾。」

這些概念的差別之處表現爲自動化程度的區別，但它們都適用於一套更爲宏觀的開發框架。整個流程能夠總結爲:首先進行持續集成，然後是持續交付或持續部署。咱們能夠把持續部署看做是持續交付的升級版。可是在集成、構建和測試完成以前，不會有任何代碼被實際部署——這就是爲何咱們要將持續集成放在首位。

專家們對於把這些概念付諸實踐的最佳建議是從小處着手，而後在每一次迭代中做出小範圍改進。最終，你們將再也不專一於單個問題，而是構建起一套可以經過自動化機制實現速度與安全性保障的架構。

Berent-Spillson的建議是，「從持續構建開始，而後提交給自動化測試（測試金字塔），並開始進行持續集成。隨着你對持續集成的效果愈發滿意，同時不斷改進你的自動化部署方案，最終須要確保回滾的無縫化實現能力。」

他解釋稱，由於回滾難度有所降低，這種方法將使得持續部署變得更容易。「在遇到錯誤的時候，你們能夠進行回滾，而後問本身，‘咱們可以如何利用自動化、感知化或測試手段來防止這一問題的發生?’」

給領導者們的經驗教訓

• 若是您所作的只是持續構建和持續集成，那麼您頗有可能會形成瓶頸並減緩整個部署過程。咱們的目標是實現頻繁發佈，這意味着您須要更高水平的自動化機制以更快地進行版本發佈。
• 在每次迭代中進行部分自動化或改進，直到您最終達到全面自動化。你們能夠列出一張清單或一張圖表，從而確保至關努力能幫助自身朝着目標穩步前進。
• 在持續集成以後，使用持續交付。只有在解決了持續交付中的合規性與管理問題、而且可以實現無縫回滾以後，您才能夠進一步嘗試持續部署。持續部署應是軟件發佈當中人爲介入程度最低的自動化階段。

原文連接：The quickie guide to continuous delivery in DevOps （翻譯：馬申君）

=========================================== 譯者介紹 馬申君，代爾夫特理工大學計算機專業的研究生，研究方向是雲資源的彈性伸縮和workflow的調度。