本指南適用於：

• 你在科技領域就職，是產品經理或者MBA。你的團隊玩A/B測試，特性切換，你辦公室裡還有一條狗。當然，你已經理解啥是功能分支，什麼是CD以及DevOps文化是什麼樣子。對不？嗯，當然。
• 你已經走在敏捷的路上，工程團隊現在每週都跟你的產品人員會面，討論故事和迭代。他們協作良好，對構建的東西感覺也越來越好。可你的客戶仍然不能更快的獲得這些功能。你仍然得等著發行列車離開車站。你已經聽到過像Esty,Flickr,Google等這些公司每天能交付100次，他們咋做到的呢？
• 你的開發團隊想要實施“CD”（譯者注：Continuous delivery – 持續交付）。你已經聽到過一些好事兒，但是你同時也擔心，這些變更進入產品卻沒有經過適當的測試，或者不能對這些變化進行適當的營銷。那麼，CD到底是什麼？

我在這裡將揭開這些實踐的神祕面紗，告訴你“在商業方面”他們到底有多麼重要，並且讓你參與進來。這其實並不複雜，我們有圖示和所有的一切資訊。

讓我們從一些概念定義和例子開始吧。

持續整合（CI – Continuous Integration）

在傳統的軟體開發中，整合過程通常在每個人完成工作之後、在專案結束階段進行。整合過程通常需要數週乃至數月的時間，可能會非常痛苦。持續整合是一種在開發週期的早期階段進行整合的實踐，以便構建、測試、整合程式碼可以更經常的進行。

CI意味著一個在家裡的筆記本上寫程式碼的開發者（比如Steve）和另外一位在辦公室桌上寫程式碼的開發人員（比如Annie）可以分別為同一款產品編寫軟體，將他們的修改合併在一個稱為原始碼庫的地方。然後他們可以從各自編寫併合並在一起的程式碼中構建軟體，並測試它是否按照他們期望的方式工作。

開發人員通常使用稱為CI伺服器的工具來為其構建和整合。CI要求Steve和Annie有能自我測試的程式碼。這些程式碼測試自身確保它們能按預期執行。通常這些測試被稱為單元測試。在整合程式碼後，當所有的單元測試通過，Steve和Annie會獲得綠色構建版本。這表明他們已經驗證他們的更改成功的整合在了一起，並且程式碼正如測試所預期的那樣工作。

不過，儘管整合的程式碼能成功的工作，但仍然不能投產，因為它還沒有在類似生產環境中測試和驗證以表明能夠工作。

你可以在下面“持續交付”一節中，閱讀在完成CI之後的更多資訊。

為了實踐CI，Steve和Annie必須提交程式碼到主要的原始碼倉庫，密集、經常的整合和測試他們的程式碼。通常每小時多次，但是每天至少一次。

CI的優點在於，整合程式碼變成了“非事件”（譯註：意思是它總在發生，出錯也不奇怪）。軟體一直在編寫和整合。在搞CI以前，程式碼整合發生在建立過程結束之後，所有整合一次性完成，然後花費的時間未知。現在有了CI，程式碼整合每天都在發生，只需要花費幾分鐘的時間。它僅是我們的工作方式。

你的團隊很有可能正在搞CI（或者至少他們相信自己正在搗鼓）。你可以通過詢問他們是否每天都整合程式碼來進行確認。CI是進行持續交付所需的第一種實踐。事實上，如果你曾經簽入過幫助文字、文件或圖片，那麼你可能已經在一直在不斷的整合。

持續交付（Continuous Delivery – CD）

讓我們回到兩位開發者Steve和Annie身上。持續交付意味著每次Steve或Annie對程式碼進行更改、整合和構建時，他們也會在與生產環境非常相似的狀態下進行自動的程式碼測試。我們稱這一系列的“部署-測試”到不同環境的操作為部署流水線。通常來說，部署流水線有一個開發環境，一個測試環境，還有一個準生產環境，但是這些階段因團隊，產品和組織各異。例如，我們的Mingle團隊有一個稱為“蛋糕”的準生產環境，而Etsy的準生產環境叫做“公主”。（譯註：消除開發環境和生產環境差異，參考Docker技術體系）

在每個不同的環境中，Annie或Steve寫的程式碼被分別測試。這給了他們越來越多的信心。對你而言，就是程式碼被部署到生產環境中時，它能夠工作。至關重要的是，程式碼只有在部署流水線中通過了前面的測試，才能提升到下一個測試環境。這樣，Annie和Steve可以從每個環境的測試中獲得新的反饋。如果出現了錯誤，他們可以更容易的理解問題到底在哪裡，並且在程式碼進入生產環境之前修復它們。

持續學習（Continuously Learning）

這個過程非常有助於我們的工作。這意味著如果Annie的測試在所有的環境中獲得通過，你就可以知道她的程式碼在生產環境中也應該如同預期一般工作。一旦所有的環境都測試通過，那麼你可以立即決定你的使用者是否能夠獲得。我們現在想要這種綠色構建用於生產中麼？當然啦！並且，隨著你的開發人員完成構建，新的、充分測試的、能工作的軟體立馬就能提供給客戶。爽歪歪！

持續部署（Continuous Deployment）

這是一種實踐，即：Steve和Annie所做的每一項變更，在通過所有的測試階段之後，自動的投入生產環境。Tim Fitz首先提出了一個很好的解釋。有些公司這麼幹，有些則不這樣做。想要實現持續部署，首先要實現持續交付。因此在開始實踐CD之前，決定哪個更適合你是不重要的。無論哪種方式，我認為持續交付是關於有助於整個業務能力的事情，因此你至少應該參與決定是否使用持續部署。畢竟，如果你正在閱讀這篇文章，那麼你可能就是在“業務方面”。

DevOps（開發與運維 – Development and Operations）

“DevOps”一詞源自“開發-Development”和“運維-Operations”的詞彙組合。DevOps是一種促進開發人員（比如Steve和Annie）和其他專業技術人員（如5星級運維明星Joey） – 通常稱為運維 – 之間合作的文化。具體來說，就是在軟體交付和部署過程中的溝通與協作，旨在更快、更可靠的的釋出更高質量的軟體。

擁有所謂DevOps文化的組織其共同特徵是：自主的具備多種技能的團隊（Steve，Annie，Joey都在同一團隊），高水平的測試和釋出自動化（持續交付）和具有共同目標、有多種技能的團隊成員。

你可能會發現在你的組織裡可以使用的一種模式是，我們的開發者Steve和Annie將和運維人員比如Joey合作，交付成品軟體，而不是僅僅將他們剛完成的程式碼“交給”Joey去釋出。同樣的，Steve，Annie和Joey都將作為公共產品或服務團隊的一員，他們一起負責產品的支援與維護，而不是讓運維團隊單獨負起支援的責任。

你還會看到行動的自動化對於執行CD和DevOps的組織來說越來越重要。這是因為，為了實現我們期望從CD和DevOps中獲得的可重複、定期和成功釋出軟體的過程，組織必須轉向自動化。手工流程很容易出錯並且效率低下。

DevOps文化通常與持續交付相關聯，因為它們都旨在增加開發人員和運維團隊之間的協作，並且都使用自動化流程去更快速、頻繁、可靠的構建、測試和釋出軟體。人們喜歡我們想要的所有這些東西。

下一步是什麼？

雖然開發團隊經常看到流程改進所帶來的立竿見影的好處，但是CI，CD和DevOps對我們其他人來說也有很多好處。簡而言之，我相信組織實踐CD和擁抱DevOps文化，將能為它們的客戶交付更有價值、更為可靠的軟體，而且更頻繁。這是不是很贊，對吧？特別是如果你在“商業方面”（更多的客戶信賴，更多的訂單）。

下次我會繼續討論更多為什麼你應該關心這些概念。我將討論它對你的業務的影響以及如何介入。如果你有任何問題，請在評論中與我交流。這些內容的要點就是告知你、賦予你有關與業務相關的技術實踐資訊。問題很棒，歡迎提問！

有用的術語

Checking in – 簽入

將本地開發的程式碼變更推送到通用程式碼倉庫的過程。（譯註：也稱為Commit，提交）

CI Server – 持續整合伺服器

用於構建和測試原始碼的工具。CI伺服器會告訴開發人員他們最新的程式碼構建是否成功，以及它們是否繼續通過測試。

Development environment – 開發環境

開發人員建立、整合、構建和測試程式碼的地方。

Deployment pipeline – 部署流水線

這是Steve和Annie的程式碼在完成並準備好交付到生產環境之前，所經歷的一系列階段。通常來說，這些將是“構建、單元測試、功能測試、效能測試、部署”。不同的自動化測試將在不同的階段執行。只有程式碼貫穿整個部署流水線，才能將軟體交付到生產環境。

Green build – 綠色構建

綠色是成功的標誌。綠色版本或構建，是通過測試開發和交付流程的特定階段的一個版本。一般情況下，一個構建或版本是不會升級到部署流水線的下一個階段的，除非它是綠色的。綠色構建的反面是紅色構建（見下文）

Incremental development – 增量開發

不要與迭代開發混淆了（見下文）。增量開發是指一次完成一小部分產品的構建，直到全部完成。每次增量中都新增一部分，這些增量可能很小或很大。你可以通過增量開發來使用CI，但是使用增量開發可能難以實現持續交付或持續部署，因為你必須等到所有增量完成之後才能交付價值。解釋增量式和迭代式開發之間差異的一個很好例子，是Jeff Paton的蒙娜麗莎。(譯註：見下圖的說明，意思就是達到目標的不同方式)

增量開發

迭代開發

Integration – 整合

所有由個人或團隊編寫的程式碼都需要合併。我們稱之為整合。在持續整合中，我們通常指的是來自個體的軟體程式碼需要定期合併。在持續交付中，我們通常指的是來自不同團隊的軟體整合在一起以建立整個產品。

Iterative development – 迭代開發

不要與增量開發混淆（見上文）。迭代開發是從一點點開始逐次構建產品，不斷完善直到完成。產品是迭代開發的，意味著同樣的部分每次迭代都要改進。在不同的迭代版本中功能特性有別，在這之間計劃和預期產品的變更。你可以使用持續整合、持續交付或持續部署進行迭代開發。增量式和迭代式開發之間的差異，見上圖。

Master/trunk/mainline – (譯註：原始碼管理系統中的分支概念，細節可以參考下Git程式碼管理系統)

“Master/trunk/mainline”是原始碼倉庫的主要分支，即主線。大多數人都在主幹上進行開發，這意味著他們要始終將其變更整合到主線。另一些則在單獨的開發人員有自己的分支時，進行基於分支的開發，或者團隊將具有不同特性的分支。

Production environment – 生產環境

這是軟體部署或釋出的地方。使用你的產品或網站的客戶最有可能使用此環境。也可以稱之為：“在生產中”，“在產品中”，“線上”。

Red build – 紅色構建

紅色表示失敗。紅色版本或構建，是指在開發和交付流程中，未通過特定階段測試的版本。通常，如果軟體的的構建是紅色的，則不會將其提升到部署流水線的下一個階段的。紅色構建的反面是綠色構建。

Source repository – 原始碼庫

這是原始碼所在的地方。Steve和Annie有他們自己正在上面工作的原生程式碼版本（意味著程式碼在他們自己的機器上），但是在開發人員提交修改的程式碼後，原始碼庫將包含所有的程式碼。

Test automation – 自動化測試

持續整合和持續交付需要高質量的自動化測試。測試是檢查軟體是否按預期工作的方法。自動化測試是程式碼編寫的測試，能夠在程式碼簽入公共原始碼庫後自動執行。

在CI世界中，每次軟體整合和構建時都會執行單元測試。如果測試沒有通過，那個軟體版本就會被確定為不能工作，“紅色”，“中斷”。在這種情況發生時，有些工作場合會出現“紅燈”或者悲傷的聲音（提示構建失敗）。

如果構建失敗了，Steve和Annie（無論誰提交的錯誤程式碼）需要修復它，讓它變綠色，讓它能夠工作。他們可以通過修改程式碼來修復它，或者移除前面造成中斷的更改。

Unit tests – 單元測試

單元測試是程式碼中的自動化測試，通過測試低階、單片的程式碼以確保它們可用和按預期工作。單元測試被認為是實施CI和CD的先決條件。（譯註：單元測試在好多語言、框架裡都有很好的支援）

進一步閱讀

持續交付：通過構建、測試和部署自動化實現可靠的軟體釋出

http://martinfowler.com/books/continuousDelivery.html

Martin Fowler關於持續整合的易讀指南

http://www.martinfowler.com/articles/continuousIntegration.html

鳳凰專案：一個IT運維的傳奇故事（此書已經由圖靈公司在國內出版發行）

http://www.ituring.com.cn/book/1545

本文由博主翻譯，原文來自：https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us

作者部落格