【編者的話】時至今日，以幾乎相同的步調實現開發與交付已經成為一種必需。本份快速指南將幫助大家弄瞭解持續交付概念中的那些“良方”與“毒藥”。
開發人員總是面臨著軟體釋出規模與速度層面的種種壓力，而這亦促使其採用各類新型概念和工具。但是，令人困惑的術語混淆了真正的技術和商業利益，特別是考慮到供應商也擁有自己的傾向與訴求。如果您需要的是真正的技術手段而非營銷口號，大家往往會發現自己很難為持續構建與交付的實現找到最佳方法。本文將為大家帶來與持續交付相關的基礎知識，希望能夠為各位帶來一點啟示。
首先，以下術語適用於同一生產流程的不同部分，而各個部分的自動化程度皆不盡相同。
-
**持續整合（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的排程。