給產品經理講講，什么是持續交付和DevOps（產品交付經理做什么的）

本指南適用于：

你在科技領域就職，是產品經理或者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以前，代碼集成發生在創建過程結束之后，所有整合一次性完成，然后花費的時間未知?，F在有了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文化通常與持續交付相關聯，因為它們都旨在增加開發人員和運維團隊之間的協作，并且都使用自動化流程去更快速、頻繁、可靠的構建、測試和發布軟件。人們喜歡我們想要的所有這些東西。

#下一步是什么？#

雖然開發團隊經?？吹搅鞒谈倪M所帶來的立竿見影的好處，但是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世界中，每次軟件集成和構建時都會運行單元測試。如果測試沒有通過，那個軟件版本就會被確定為不能工作，“紅色”，“中斷”。在這種情況發生時，有些工作場合會出現“紅燈”或者悲傷的聲音（提示構建失?。?/p>

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

Unit tests – 單元測試

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

#進一步閱讀#

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

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

Martin Fowler關于持續集成的易讀指南

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

鳳凰項目：一個IT運維的傳奇故事

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

DevOps 單元測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。