理解 CI 和 CD 之間的區別（翻譯）

博客搬遷至https://blog.wangjiegulu.com

RSS訂閱：https://blog.wangjiegulu.com/feed.xml

原文連接：https://blog.wangjiegulu.com/2018/09/10/understanding-the-difference-between-ci-and-cd/

理解 CI 和 CD 之間的區別

原文：https://thenewstack.io/understanding-the-difference-between-ci-and-cd/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

有不少關於持續集成（CI）和持續交付（CD）的資料。不少文章用技術術語來進行解釋，以及它們怎麼幫助你的組織。惋惜的是，在一些狀況下，這些方法一般與特定工具、甚至供應商相關聯。在公司食堂裏很是常見的談話多是：

1. 你在大家團隊裏面使用持續集成嗎？
2. 固然，咱們使用 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 高興地宣佈，該版本已經打包好，並運往客戶。

那麼，人們面對這個虛構的（又很是現實）的故事是什麼感覺呢？

1. Alice, Bob, 和 Charlie（開發）都不高興，由於他們老是在發佈即將發生以前瞭解集成問題。集成期感受就像交火, 同一時刻出現不少問題。
2. David（測試）也不高興，由於他的工做實在不平衡。當他在等待開發在 feature 完成它們的工做的時候是和平時期。而後在測試階段他陷於測試工做中，須要處理意想不到的測試場景，而且每一個人都站在他的肩旁上看他。
3. Elizabeth（管理人員）也不高興。集成階段是項目的關鍵路徑。這是一個緊張的時期, 任何意想不到的問題,都會阻礙推進產品的進一步交付。Elizabeth 一直夢想軟件發佈沒有任何意外狀況, 但這在現實中歷來不會發生。項目時間線中的集成階段總變成一個猜謎遊戲。

團隊的每一個人都不高興（順便一提，若是你的公司仍然在這樣開發軟件，請嘗試瞭解這種開發工做流對團隊的士氣形成的損害）。

這裏的主要問題是單一的「集成」階段發生在每一個產品發佈。這是工做流的難點，它阻礙了團隊進行無壓力發佈過程。

在集成中增長「持續」

如今咱們已經知道了什麼是「集成」，很容易理解「持續集成」的須要之處。俗話說，「若是某事是痛苦的，那就多作它」。持續集成實質上是經過高頻率的重複集成步驟減輕它的痛苦。最顯而易見的方法就是在每次 feature 合併後進行集成（而不是在宣佈正式 release 以前等待）。

當一個團隊實踐持續集成...

1. 全部 feature 分支都直接合併到主分支（主線）中。
2. 開發人員不是孤立工做的。全部 feature 都是從主線開始開發的。
3. 若是主線是健康的，而不是在它單獨的工做站上工做，則一項 feature 被視爲已完成。
4. 測試在 feature 級別和主線級別都會被觸發。

這些是持續集成的要點！固然，還有更多的細節（實際上關於這個主題有一本完整的書籍）。可是重要的一點是，全部合併和測試並非在一個單一的有壓力的集成時刻，集成一直在連續的時刻發生。

持續集成是開發軟件的一種更好的方法（相比於「簡單」集成），由於它：

1. 減小在合併 feature 時出現的意外次數。
2. 解決「在個人機子上沒問題」的問題
3. 將測試周期切片到每一個 feature 逐漸合併到主線中的階段（而不是一次性的）。

其結果就是，一個使用 CI 的團隊不是生活在過山車上 (在開發時期很平靜，伴隨着的是有壓力的 release)，而是能夠在如何接近完成項目的漸進方式中獲得更好的可見性。

利用 CI 工做是現代軟件開發的支柱之一。這一點上，該技術被很是好的記錄和知曉。若是如今大家的軟件項目中尚未實踐 CI，你的組織沒有任何藉口不去實踐它。

軟件交付的黑暗時代

如今咱們知道了 「集成」 的歷史，以及持續集成的工做原理，咱們能夠將它帶到一個下一級，持續交付。

若是咱們回到原來的故事，咱們能夠看到相似模式的發佈方式正在發生：

執行 Release 發佈實質上是一個「大爆炸」事件。在軟件被認爲已經測試過，有人會負責包裝和部署的過程。部署軟件到生產也是一個很是有壓力的階段，傳統來講會涉及到不少手動的步驟（和 checklists）。部署多是不多次的（有的公司每六個月纔會部署一次）。在極端狀況下，部署可能只發生一次（瀑布流設計方法）。

只有到 deadline 時才交付軟件，這會出現與不頻繁集成同樣的挑戰：

1. 一般發現生產環境與須要在最後一刻進行額外配置的測試環境不一樣。
2. 在測試環境中工做正常的功能在生產中被發現問題。
3. 在發佈時尚未準備就緒的功能，或者根本就不會交付給客戶，或者他們進一步推遲發佈日期。
4. 發佈致使開發人員（想要發佈新功能）和運營（想要穩定，不想一次部署太多的新功能）之間的關係變得緊張。

你應該能理解這裏的模式。若是咱們經過更頻繁地來緩解「集成」階段的痛苦，咱們也能夠爲「交付」階段作一樣的事情。

在交付中增長「持續」

持續交付是儘量頻繁地組裝和準備軟件（就像它會被髮布到生產那樣）的實踐。最極端的交付方式是在每一個 feature 合併以後。

所以，CD，讓 CI 走得更遠一步。在每一個 feature 合併到主線中，軟件不只要測試正確性，並且也要包裝和部署到測試環境（比較理想地符合生產環境）。全部這一切都是以徹底自動化的方式。注意，上圖中缺乏的草圖 (表示手動步驟)。

還要注意，每一個 feature 都是推送到生產的潛在候選者。不是全部候選人都會被髮送到生產。根據組織，部署到生產的決定須要人工干預，人類只決定一個 release 是否應該發送到生產（但不會準備這個 release 自己）。這個 release 在測試環境已經被打包，測試和部署。

持續交付比持續集成更難採用。其緣由是由於每一個發佈候選者都有可能達到生產，所以須要自動化整個生命週期：

1. 構建應該是可重複性和肯定性的。
2. 全部 release 步驟應該都是自動化的（它比聽起來更難）。
3. 全部的配置和關聯的文件都應該存在於代碼控制中 (而不只僅是源代碼)。
4. 每一個 feature / release 都應該在它的測試環境中被測試過（以動態方式建立和銷燬的理想方法）。
5. 全部測試套件都應自動化且相對快速（它也是比聽起來更難）。

雖然雲固然能夠幫助知足全部這些要求，但在軟件團隊 (開發人員和運營部門) 中須要必定程度的紀律，以便真正擁抱持續交付。

一旦 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 的方式,，以下圖所示：

請確保以正確的順序處理每一個開發模式。針對持續交付是一個更現實的目標，可選的工具也很豐富。