翻譯：The Product Managers’ Guide to Continuous Delivery and DevOps (産品經理持續傳遞和DevOps指南)
原文連結：https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/
相關術語
- 持續內建(continuous integration，簡稱CI)
- 持續傳遞(continuous delivery，簡稱CD)
- 持續部署(continuous deployment)
- DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用于促進開發（應用程式/軟體工程）、技術營運和品質保障（QA）部門之間的溝通、協作與整合。
- Agile Software Development : 靈活開發。
文章目錄
-
- Continuous Integration (CI) --- 持續內建
- Continuous Delivery (CD) --- 持續傳遞
- Continuously Learning --- 持續學習
- Continuous Deployment --- 持續部署
- DevOps
- 下一步是什麼?
- Useful Terminology --- 常用的術語
-
- Checking in --- 簽入/檢入
- CI server --- 持續內建伺服器
- Development environment --- 開發環境
- Deployment pipeline/pipeline --- 部署流水線/開發産品線
- Green build --- 綠色建構
- Incremental development --- 增量式開發
- Integration --- 內建
- Iterative development --- 疊代開發
- Master/trunk/mainline --- 主要分支
- Production environment --- 生産環境
- Red build --- 紅色建構
- Source repository --- 源代碼庫
- Test automation --- 自動化測試
- Unit tests --- 單元測試
- 內建、傳遞、部署了解總結（補充）
- 進一步閱讀
- 參考
正文翻譯
在這個指南中，我緻力于揭開持續傳遞和DevOps的神秘面紗。我将解釋這些實踐，告訴您它們對您“在業務方面”有多重要，并幫助您參與其中。這并不複雜，下面用詳細的圖例說明。
本指南适合您……
- 您擁有技術，您是産品經理或MBA。您的團隊需要進行A/B測試，功能特性切換/功能分支（Feature Toggle）和 you have a dog in the office！當然，您了解什麼是功能分支，什麼是CD以及DevOps文化是什麼樣的。對？嗯…當然。
- 你以參與靈活開發了。現在，工程團隊每周都會與您的産品人員開會，讨論故事和疊代。他們合作得很好，正在建設的東西比以往任何時候都感覺更好。但是您的客戶仍然無法更快地獲得這些功能。You still have to wait for the release train to leave the station.（您仍然必須等待釋放火車離開車站)。您聽說過像Etsy，Flickr和Google這樣的公司每天傳遞100次。他們是如何做到的呢？
- 您的開發團隊希望“做CD（持續傳遞）”。您已經聽到了一些好消息，但是，您還會擔心在沒有進行适當測試或不能正确地将更改推向市場的情況下将更改推向生産環境。CD是指什麼？
讓我們從一些定義和示例開始：
Continuous Integration (CI) — 持續內建
在傳統的軟體開發中，整合過程通常在每個人完成工作之後、在項目結束階段進行。整合過程通常需要數周乃至數月的時間，可能會非常痛苦。持續內建是一種在開發周期的早期階段進行內建的實踐，以便建構、測試、整合代碼可以更經常的進行。
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
“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文化，将能為它們的客戶傳遞更有價值、更為可靠的軟體，而且更頻繁。這是不是很贊，對吧？特别是如果你在“商業方面”（更多的客戶信賴，更多的訂單）。
下次我會繼續讨論更多為什麼你應該關心這些概念。我将讨論它對你的業務的影響以及如何介入。如果你有任何問題，請在評論中與我交流。這些内容的要點就是告知你、賦予你有關與業務相關的技術實踐資訊。問題很棒，歡迎提問！
Useful Terminology — 常用的術語
Checking in — 簽入/檢入
将本地開發的代碼變更推送到通用代碼倉庫的過程。（譯注：也稱為Commit，送出）
CI server — 持續內建伺服器
用于建構和測試源代碼的工具。CI伺服器會告訴開發人員他們最新的代碼建構是否成功，以及它們是否繼續通過測試。
Development environment — 開發環境
開發人員建立、內建、建構和測試代碼的地方。
Deployment pipeline/pipeline — 部署流水線/開發産品線
這是Steve和Annie的代碼在完成并準備好傳遞到生産環境之前，所經曆的一系列階段。通常來說，這些将是“建構、單元測試、功能測試、性能測試、部署”。不同的自動化測試将在不同的階段運作。隻有代碼貫穿整個部署流水線，才能将軟體傳遞到生産環境。
Green build — 綠色建構
綠色是成功的标志。綠色版本或建構，是通過測試開發和傳遞流程的特定階段的一個版本。一般情況下，一個建構或版本是不會更新到部署流水線的下一個階段的，除非它是綠色的。綠色建構的反面是紅色建構（見下文）
Incremental development — 增量式開發
不要與疊代開發混淆了（見下文）。增量開發是指一次完成一小部分産品的建構，直到全部完成。每次增量中都添加一部分，這些增量可能很小或很大。你可以通過增量開發來使用CI，但是使用增量開發可能難以實作持續傳遞或持續部署，因為你必須等到所有增量完成之後才能傳遞價值。解釋增量式和疊代式開發之間差異的一個很好例子，是Jeff Paton的蒙娜麗莎。(譯注：見下圖的說明，意思就是達到目标的不同方式)
Integration — 內建
所有由個人或團隊編寫的代碼都需要合并。我們稱之為內建。在持續內建中，我們通常指的是來自個體的軟體代碼需要定期合并。在持續傳遞中，我們通常指的是來自不同團隊的軟體內建在一起以建立整個産品。
Iterative development — 疊代開發
不要與增量開發混淆（見上文）。疊代開發是從一點點開始逐次建構産品，不斷完善直到完成。産品是疊代開發的，意味着同樣的部分每次疊代都要改進。在不同的疊代版本中功能特性有别，在這之間計劃和預期産品的變更。你可以使用持續內建、持續傳遞或持續部署進行疊代開發。Jeff Paton的《蒙娜麗莎》是增量開發和疊代開發之間差別的一個很好的例子。
Master/trunk/mainline — 主要分支
(譯注：源代碼管理系統中的分支概念，細節可以參考下Git代碼管理系統)
“Master/trunk/mainline”是源代碼倉庫的主要分支，即主線。大多數人都在主幹上進行開發，這意味着他們要始終将其變更內建到主線。另一些則在單獨的開發人員有自己的分支時，進行基于分支的開發，或者團隊将具有不同特性的分支。
Production environment — 生産環境
這是軟體部署或釋出的地方。使用你的産品或網站的客戶最有可能使用此環境。也可以稱之為：“在生産中”，“在産品中”，“線上”。
Red build — 紅色建構
紅色表示失敗。紅色版本或建構，是指在開發和傳遞流程中，未通過特定階段測試的版本。通常，如果軟體的的建構是紅色的，則不會将其提升到部署流水線的下一個階段的。紅色建構的反面是綠色建構。
Source repository — 源代碼庫
這是源代碼所在的地方。Steve和Annie有他們自己正在上面工作的本地代碼版本（意味着代碼在他們自己的機器上），但是在開發人員送出修改的代碼後，源代碼庫将包含所有的代碼。
Test automation — 自動化測試
持續內建和持續傳遞需要高品質的自動化測試。測試是檢查軟體是否按預期工作的方法。自動化測試是代碼編寫的測試，能夠在代碼簽入公共源代碼庫後自動運作。
在CI世界中，每次軟體內建和建構時都會運作單元測試。如果測試沒有通過，那個軟體版本就會被确定為不能工作，“紅色”，“中斷”。在這種情況發生時，有些工作場合會出現“紅燈”或者悲傷的聲音（提示建構失敗）。
如果建構失敗了，Steve和Annie（無論誰送出的錯誤代碼）需要修複它，讓它變綠色，讓它能夠工作。他們可以通過修改代碼來修複它，或者移除前面造成中斷的更改。
Unit tests — 單元測試
單元測試是代碼中的自動化測試，通過測試低級、單片的代碼以確定它們可用和按預期工作。單元測試被認為是實施CI和CD的先決條件。（譯注：單元測試在好多語言、架構裡都有很好的支援）
內建、傳遞、部署了解總結（補充）
來自：https://www.zhihu.com/question/23444990 趙劼
內建是指軟體個人研發的部分向軟體整體部分傳遞，以便盡早發現個人開發部分的問題；
部署是代碼盡快向可運作的開發/測試節傳遞，以便盡早測試；
傳遞是指研發盡快向客戶傳遞，以便盡早發現生産環境中存在的問題。
如果說等到所有東西都完成了才向下個環節傳遞，導緻所有的問題隻能再最後才爆發出來，解決成本巨大甚至無法解決。
而所謂的持續，就是說每完成一個完整的部分，就向下個環節傳遞，發現問題可以馬上調整。是的問題不會放大到其他部分和後面的環節。
這種做法的核心思想在于：既然事實上難以做到事先完全了解完整的、正确的需求，那麼就幹脆一小塊一小塊的做，并且加快傳遞的速度和頻率，使得傳遞物盡早在下個環節得到驗證。早發現問題早返工。
進一步閱讀
- 持續傳遞：通過建構、測試和部署自動化實作可靠的軟體釋出
- Martin Fowler關于持續內建的易讀指南
- 鳳凰項目：一個IT運維的傳奇故事
- 持續傳遞:産品經理的超能力
參考
- https://www.zhihu.com/question/23444990
- 給産品經理講講，什麼是持續傳遞和DevOps
- devops （過程、方法與系統的統稱）
- AB測試
- Feature Toggle - Martin Fowler
- 網際網路靈活DevOps和自動化之1.DevOps
- 5 大 DevOps 工具，你用過幾個？
- 26 Hints for Agile Software Development(靈活開發的26條建議)
- 靈活開發之 12條靈活原則
- 靈活軟體開發—維基百科