有很多關於持續整合（CI）和持續交付（CD）的資料。很多文章用技術術語來進行解釋，以及它們怎麼幫助你的組織。可惜的是，在一些情況下，這些方法通常與特定工具、甚至供應商相關聯。在公司食堂裡非常常見的談話可能是：
- 你在你們團隊裡面使用持續整合嗎？
- 當然，我們使用 X 工具
讓我來告訴你一些祕密。持續整合和持續交付都是開發方法。它們沒有連結到特定的工具或者供應商。儘管有DO（比如Codefresh）這樣的工具和解決方法在這兩方面幫助你，實際上，一個公司可以只使用 Bash 指令碼和 Perl one-liners（不是真的使用，但是有可能的）來練習 CI / CD。
所以，我們不會陷入使用工具和技術術語來解釋 CI / DI 的陷阱，我們將用最重要的東西來解釋：人！
關於人的故事 — 軟體整合的黑暗時代
Alice, Bob, Charlie, David, 和 Elizabeth，他們都在 SoftwareCo 公司。開發 SuperBigProject 應用。Alice, Bob, 和 Charlie 是開發者。David 是一個測試工程師。Elizabeth 是團隊的專案經理。
開發應用的傳統方法如下：
Alice, Bob, 和 Charlie 在它們各自的工作區，工作在3個不同的 feature。每個開發人員都以各自的方法編寫和測試程式碼。他們使用一個長週期的 feature 分支，在它們合併進生產之前可能存在幾周或者甚至幾個月。
在某個時間點，Elizabeth（PM）召集整個團隊，並宣佈：“各位，我們需要構建一個 Release”。
此時，Alice, Bob, 和 Charlie 爭先恐後地整合所有3個 feature 分支到同一個分支中。這是一個非常緊張的時刻，因為這些分支之前並沒有合併一起進行測試過。由於錯誤的假設或者環境原因，會出現很多bug和問題（請記住，目前為止，所有 feature 僅僅在各自的工作站中進行過測試，彼此是隔離的）。
一旦這個高度緊張的時期結束了，合併的結果將傳遞給將執行額外的手動和自動測試的 David，此期間也很耗時, 因為他是可以根據發現的決定性 bug 的數量來批准或阻止釋出的人。當他測試時, 所有的目光都落在了大衛身上, 因為他的測試可以暴露出嚴重的問題, 會導致 Release 的 delay。
最後，測試結束了，Elizabeth 高興地宣佈，該版本已經打包好，並運往客戶。
那麼，人們面對這個虛構的（又非常現實）的故事是什麼感受呢？
- Alice, Bob, 和 Charlie（開發）都不高興，因為他們總是在釋出即將發生之前瞭解整合問題。整合期感覺就像交火, 同一時刻出現很多問題。
- David（測試）也不高興，因為他的工作實在不平衡。當他在等待開發在 feature 完成它們的工作的時候是和平時期。然後在測試階段他陷於測試工作中，需要處理意想不到的測試場景，並且每個人都站在他的肩旁上看他。
- Elizabeth（管理人員）也不高興。整合階段是專案的關鍵路徑。這是一個緊張的時期, 任何意想不到的問題,都會阻礙推動產品的進一步交付。Elizabeth 一直夢想軟體釋出沒有任何意外情況, 但這在現實中從來不會發生。專案時間線中的整合階段總變成一個猜謎遊戲。
團隊的每個人都不高興（順便一提，如果你的公司仍然在這樣開發軟體，請嘗試瞭解這種開發工作流對團隊的士氣造成的損害）。
這裡的主要問題是單一的“整合”階段發生在每個產品釋出。這是工作流的難點，它阻礙了團隊進行無壓力釋出過程。
在整合中增加“持續”
現在我們已經知道了什麼是“整合”，很容易理解“持續整合”的需要之處。俗話說，“如果某事是痛苦的，那就多做它”。持續整合實質上是通過高頻率的重複整合步驟減輕它的痛苦。最顯而易見的方法就是在每次 feature 合併後進行整合（而不是在宣佈正式 release 之前等待）。
當一個團隊實踐持續整合…
- 所有 feature 分支都直接合併到主分支（主線）中。
- 開發人員不是孤立工作的。所有 feature 都是從主線開始開發的。
- 如果主線是健康的，而不是在它單獨的工作站上工作，則一項 feature 被視為已完成。
- 測試在 feature 級別和主線級別都會被觸發。
這些是持續整合的要點！當然，還有更多的細節（實際上關於這個主題有一本完整的書籍）。但是重要的一點是，所有合併和測試並不是在一個單一的有壓力的整合時刻，整合一直在連續的時刻發生。
持續整合是開發軟體的一種更好的方法（相比於“簡單”整合），因為它：
- 減少在合併 feature 時出現的意外次數。
- 解決“在我的機子上沒問題”的問題
- 將測試周期切片到每個 feature 逐漸合併到主線中的階段（而不是一次性的）。
其結果就是，一個使用 CI 的團隊不是生活在雲霄飛車上 (在開發時期很平靜，伴隨著的是有壓力的 release)，而是可以在如何接近完成專案的漸進方式中得到更好的可見性。
利用 CI 工作是現代軟體開發的支柱之一。這一點上，該技術被非常好的記錄和知曉。如果現在你們的軟體專案中還沒有實踐 CI，你的組織沒有任何藉口不去實踐它。
軟體交付的黑暗時代
現在我們知道了 “整合” 的歷史，以及持續整合的工作原理，我們可以將它帶到一個下一級，持續交付。
如果我們回到原來的故事，我們可以看到類似模式的釋出方式正在發生：
執行 Release 釋出實質上是一個“大爆炸”事件。在軟體被認為已經測試過，有人會負責包裝和部署的過程。部署軟體到生產也是一個非常有壓力的階段，傳統來說會涉及到很多手動的步驟（和 checklists）。部署可能是很少次的（有的公司每六個月才會部署一次）。在極端情況下，部署可能只發生一次（瀑布流設計方法）。
只有到 deadline 時才交付軟體，這會出現與不頻繁整合一樣的挑戰：
- 通常發現生產環境與需要在最後一刻進行額外配置的測試環境不同。
- 在測試環境中工作正常的功能在生產中被發現問題。
- 在釋出時還沒有準備就緒的功能，或者根本就不會交付給客戶，或者他們進一步推遲釋出日期。
- 釋出導致開發人員（想要釋出新功能）和運營（想要穩定，不想一次部署太多的新功能）之間的關係變得緊張。
你應該能理解這裡的模式。如果我們通過更頻繁地來緩解“整合”階段的痛苦，我們也可以為“交付”階段做同樣的事情。
在交付中增加“持續”
持續交付是儘可能頻繁地組裝和準備軟體（就像它會被髮布到生產那樣）的實踐。最極端的交付方式是在每個 feature 合併之後。
因此，CD，讓 CI 走得更遠一步。在每個 feature 合併到主線中，軟體不僅要測試正確性，而且也要包裝和部署到測試環境（比較理想地符合生產環境）。所有這一切都是以完全自動化的方式。注意，上圖中缺少的草圖 (表示手動步驟)。
還要注意，每個 feature 都是推送到生產的潛在候選者。不是所有候選人都會被髮送到生產。根據組織，部署到生產的決定需要人工干預，人類只決定一個 release 是否應該傳送到生產（但不會準備這個 release 本身）。這個 release 在測試環境已經被打包，測試和部署。
持續交付比持續整合更難採用。其原因是因為每個釋出候選者都有可能達到生產，因此需要自動化整個生命週期：
- 構建應該是可重複性和確定性的。
- 所有 release 步驟應該都是自動化的（它比聽起來更難）。
- 所有的配置和關聯的檔案都應該存在於程式碼控制中 (而不僅僅是原始碼)。
- 每個 feature / release 都應該在它的測試環境中被測試過（以動態方式建立和銷燬的理想方法）。
- 所有測試套件都應自動化且相對快速（它也是比聽起來更難）。
雖然雲當然可以幫助滿足所有這些要求，但在軟體團隊 (開發人員和運營部門) 中需要一定程度的紀律，以便真正擁抱持續交付。
一旦 CD 落地，釋出會變得微不足道，因為它們可以按個按鈕就能執行。每個人（不僅僅是專案經理）都具有 release candidate （譯者：release 候選版本，以下對此術語不做翻譯）的可見性。當前的 release candidate 可能沒有所有請求的功能，或者說它可能無法滿足所有的要求，但是這對於釋出過程來說並不重要。重要的其實是這個 release 是完整測試和打包的，準備就緒傳送到生產（如果需要）。任何專案的相關人員可以給出綠燈並立即把 release 部署到生產。
如果你使用 CD，則軟體的生命週期可以概括成如下：
每個 release candidate 都是預先預備好的。一個人決定是否一個 release candidate 版本是否推送到生產。沒有推送到生產的 Release Candidate 仍然會作為一個 artifact 儲存起來，如果將來有需要可以進行召回。
就像持續整合一樣，如果你想知道更多的細節，這裡有整本圍繞持續交付的書籍。
額外獎勵：持續部署
CD 中的 “D” 也可以表示部署（Deployment）。這種開發方法建立在持續交付上, 基本上完全消除了所有人類干預。任何被發現準備就緒的 release candidate （並且通過所有質量測試）都會立即推送到生產。
不可否認的是，只有極少數的公司可以這樣做。沒有人類干預直接推送到生產應該不能掉以輕心。在撰寫這篇文章時，許多公司甚至都沒有實踐持續交付，更別說部署了。現在應該清楚的是，每種開發方法都需要建立在之前那些基礎之上。
在向上移動之前（譯者：按上圖向上移動），你的組織應該確保每個基礎都是真正穩固的。在 Codefresh，我們已經看到了很多公司試圖進入雲時代，在他們沒有真正的理解 CI/CD 管道時試圖硬塞進現有的做法（為資料中心進行優化），並且其中一些做法現在已經過時。嘗試採用持續部署而不完全擁抱持續交付是一場失敗的戰役。
另一種方法是檢視這些方法涵蓋的內容以及 CD 需要 CI 的方式,，如下圖所示：
請確保以正確的順序處理每個開發模式。針對持續交付是一個更現實的目標，可選的工具也很豐富。
本文連結：https://blog.wangjiegulu.com/2018/09/10/understanding-the-difference-between-ci-and-cd/
版權宣告：本部落格所有文章除特別宣告外，均採用 CC BY 4.0 CN協議 許可協議。轉載請註明出處。