點擊關注 異步圖書，置頂公衆號
每天與你分享 IT好書 技術乾貨 職場知識
本指南適用於：
你在科技領域就職，是產品經理或者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運維的傳奇故事
本文來源於異步社區，作者winston ，文章《給產品經理講講，什麼是持續交付和DevOps》
推薦閱讀
長按二維碼，可以關注我們喲
每天與你分享IT好文。
在“異步圖書”後臺回覆“關注”，即可免費獲得2000門在線視頻課程；推薦朋友關注根據提示獲取贈書鏈接，免費得異步e讀版圖書一本。趕緊來參加哦！
點擊閱讀原文，查看原文