大廠技術(shù)??高級(jí)前端??Node進(jìn)階

點(diǎn)擊上方?程序員成長(zhǎng)指北，關(guān)注公眾號(hào)

回復(fù)1，加入高級(jí)Node交流群

大家好，我是 考拉??，今天我們來看一個(gè)研發(fā)中非常常見的概念，CI/CD，你有了解過它們的區(qū)別嗎？（本文由 wangjie 翻譯）

有很多關(guān)于持續(xù)集成（CI）和持續(xù)交付（CD）的資料。很多文章用技術(shù)術(shù)語來進(jìn)行解釋，以及它們?cè)趺磶椭愕慕M織?？上У氖?，在一些情況下，這些方法通常與特定工具、甚至供應(yīng)商相關(guān)聯(lián)。在公司食堂里非常常見的談話可能是：

• 你在你們團(tuán)隊(duì)里面使用持續(xù)集成嗎？
• 當(dāng)然，我們使用 X 工具

讓我來告訴你一些秘密。持續(xù)集成和持續(xù)交付都是開發(fā)方法。它們沒有鏈接到特定的工具或者供應(yīng)商。盡管有DO（比如Codefresh）這樣的工具和解決方法在這兩方面幫助你，實(shí)際上，一個(gè)公司可以只使用 Bash 腳本和 Perl one-liners（不是真的使用，但是有可能的）來練習(xí) CI / CD。

所以，我們不會(huì)陷入使用工具和技術(shù)術(shù)語來解釋 CI / CD 的陷阱，我們將用最重要的東西來解釋：人！

關(guān)于人的故事 — 軟件集成的黑暗時(shí)代

Alice, Bob, Charlie, David, 和 Elizabeth，他們都在 SoftwareCo 公司。開發(fā) SuperBigProject 應(yīng)用。Alice, Bob, 和 Charlie 是開發(fā)者。David 是一個(gè)測(cè)試工程師。Elizabeth 是團(tuán)隊(duì)的項(xiàng)目經(jīng)理。

開發(fā)應(yīng)用的傳統(tǒng)方法如下：

Alice, Bob, 和 Charlie 在它們各自的工作區(qū)，工作在3個(gè)不同的 feature。每個(gè)開發(fā)人員都以各自的方法編寫和測(cè)試代碼。他們使用一個(gè)長(zhǎng)周期的 feature 分支，在它們合并進(jìn)生產(chǎn)之前可能存在幾周或者甚至幾個(gè)月。

在某個(gè)時(shí)間點(diǎn)，Elizabeth（PM）召集整個(gè)團(tuán)隊(duì)，并宣布：“各位，我們需要構(gòu)建一個(gè) Release”。

此時(shí)，Alice, Bob, 和 Charlie 爭(zhēng)先恐后地集成所有3個(gè) feature 分支到同一個(gè)分支中。這是一個(gè)非常緊張的時(shí)刻，因?yàn)檫@些分支之前并沒有合并一起進(jìn)行測(cè)試過。由于錯(cuò)誤的假設(shè)或者環(huán)境原因，會(huì)出現(xiàn)很多bug和問題（請(qǐng)記住，目前為止，所有 feature 僅僅在各自的工作站中進(jìn)行過測(cè)試，彼此是隔離的）。

一旦這個(gè)高度緊張的時(shí)期結(jié)束了，合并的結(jié)果將傳遞給將執(zhí)行額外的手動(dòng)和自動(dòng)測(cè)試的 David，此期間也很耗時(shí), 因?yàn)樗强梢愿鶕?jù)發(fā)現(xiàn)的決定性 bug 的數(shù)量來批準(zhǔn)或阻止發(fā)布的人。當(dāng)他測(cè)試時(shí), 所有的目光都落在了大衛(wèi)身上, 因?yàn)樗臏y(cè)試可以暴露出嚴(yán)重的問題, 會(huì)導(dǎo)致 Release 的 delay。

最后，測(cè)試結(jié)束了，Elizabeth 高興地宣布，該版本已經(jīng)打包好，并運(yùn)往客戶。

那么，人們面對(duì)這個(gè)虛構(gòu)的（又非常現(xiàn)實(shí)）的故事是什么感受呢？

• Alice, Bob, 和 Charlie（開發(fā)）都不高興，因?yàn)樗麄兛偸窃诎l(fā)布即將發(fā)生之前了解集成問題。集成期感覺就像交火, 同一時(shí)刻出現(xiàn)很多問題。
• David（測(cè)試）也不高興，因?yàn)樗墓ぷ鲗?shí)在不平衡。當(dāng)他在等待開發(fā)在 feature 完成它們的工作的時(shí)候是和平時(shí)期。然后在測(cè)試階段他陷于測(cè)試工作中，需要處理意想不到的測(cè)試場(chǎng)景，并且每個(gè)人都站在他的肩旁上看他。
• Elizabeth（管理人員）也不高興。集成階段是項(xiàng)目的關(guān)鍵路徑。這是一個(gè)緊張的時(shí)期, 任何意想不到的問題,都會(huì)阻礙推動(dòng)產(chǎn)品的進(jìn)一步交付。Elizabeth 一直夢(mèng)想軟件發(fā)布沒有任何意外情況, 但這在現(xiàn)實(shí)中從來不會(huì)發(fā)生。項(xiàng)目時(shí)間線中的集成階段總變成一個(gè)猜謎游戲。

團(tuán)隊(duì)的每個(gè)人都不高興（順便一提，如果你的公司仍然在這樣開發(fā)軟件，請(qǐng)嘗試了解這種開發(fā)工作流對(duì)團(tuán)隊(duì)的士氣造成的損害）。軟件交付的黑暗時(shí)代

這里的主要問題是單一的“集成”階段發(fā)生在每個(gè)產(chǎn)品發(fā)布。這是工作流的難點(diǎn)，它阻礙了團(tuán)隊(duì)進(jìn)行無壓力發(fā)布過程。

在集成中增加“持續(xù)”

現(xiàn)在我們已經(jīng)知道了什么是“集成”，很容易理解“持續(xù)集成”的需要之處。俗話說，“如果某事是痛苦的，那就多做它”。持續(xù)集成實(shí)質(zhì)上是通過高頻率的重復(fù)集成步驟減輕它的痛苦。最顯而易見的方法就是在每次 feature 合并后進(jìn)行集成（而不是在宣布正式 release 之前等待）。

當(dāng)一個(gè)團(tuán)隊(duì)實(shí)踐持續(xù)集成…

• 所有 feature 分支都直接合并到主分支（主線）中。
• 開發(fā)人員不是孤立工作的。所有 feature 都是從主線開始開發(fā)的。
• 如果主線是健康的，而不是在它單獨(dú)的工作站上工作，則一項(xiàng) feature 被視為已完成。
• 測(cè)試在 feature 級(jí)別和主線級(jí)別都會(huì)被觸發(fā)。

這些是持續(xù)集成的要點(diǎn)！當(dāng)然，還有更多的細(xì)節(jié)（實(shí)際上關(guān)于這個(gè)主題有一本完整的書籍）。但是重要的一點(diǎn)是，所有合并和測(cè)試并不是在一個(gè)單一的有壓力的集成時(shí)刻，集成一直在連續(xù)的時(shí)刻發(fā)生。

彩蛋：你關(guān)注?code秘密花園 了嗎？

持續(xù)集成是開發(fā)軟件的一種更好的方法（相比于“簡(jiǎn)單”集成），因?yàn)樗?/p>

• 減少在合并 feature 時(shí)出現(xiàn)的意外次數(shù)。
• 解決“在我的機(jī)子上沒問題”的問題
• 將測(cè)試周期切片到每個(gè) feature 逐漸合并到主線中的階段（而不是一次性的）。

其結(jié)果就是，一個(gè)使用 CI 的團(tuán)隊(duì)不是生活在過山車上 (在開發(fā)時(shí)期很平靜，伴隨著的是有壓力的 release)，而是可以在如何接近完成項(xiàng)目的漸進(jìn)方式中得到更好的可見性。

利用 CI 工作是現(xiàn)代軟件開發(fā)的支柱之一。這一點(diǎn)上，該技術(shù)被非常好的記錄和知曉。如果現(xiàn)在你們的軟件項(xiàng)目中還沒有實(shí)踐 CI，你的組織沒有任何借口不去實(shí)踐它。

軟件交付的黑暗時(shí)代

現(xiàn)在我們知道了 “集成” 的歷史，以及持續(xù)集成的工作原理，我們可以將它帶到一個(gè)下一級(jí)，持續(xù)交付。

如果我們回到原來的故事，我們可以看到類似模式的發(fā)布方式正在發(fā)生：

執(zhí)行 Release 發(fā)布實(shí)質(zhì)上是一個(gè)“大爆炸”事件。在軟件被認(rèn)為已經(jīng)測(cè)試過，有人會(huì)負(fù)責(zé)包裝和部署的過程。部署軟件到生產(chǎn)也是一個(gè)非常有壓力的階段，傳統(tǒng)來說會(huì)涉及到很多手動(dòng)的步驟（和 checklists）。部署可能是很少次的（有的公司每六個(gè)月才會(huì)部署一次）。在極端情況下，部署可能只發(fā)生一次（瀑布流設(shè)計(jì)方法）。

只有到 deadline 時(shí)才交付軟件，這會(huì)出現(xiàn)與不頻繁集成一樣的挑戰(zhàn)：

• 通常發(fā)現(xiàn)生產(chǎn)環(huán)境與需要在最后一刻進(jìn)行額外配置的測(cè)試環(huán)境不同。
• 在測(cè)試環(huán)境中工作正常的功能在生產(chǎn)中被發(fā)現(xiàn)問題。
• 在發(fā)布時(shí)還沒有準(zhǔn)備就緒的功能，或者根本就不會(huì)交付給客戶，或者他們進(jìn)一步推遲發(fā)布日期。
• 發(fā)布導(dǎo)致開發(fā)人員（想要發(fā)布新功能）和運(yùn)營(yíng)（想要穩(wěn)定，不想一次部署太多的新功能）之間的關(guān)系變得緊張。
• 你應(yīng)該能理解這里的模式。如果我們通過更頻繁地來緩解“集成”階段的痛苦，我們也可以為“交付”階段做同樣的事情。

在交付中增加“持續(xù)”

持續(xù)交付是盡可能頻繁地組裝和準(zhǔn)備軟件（就像它會(huì)被發(fā)布到生產(chǎn)那樣）的實(shí)踐。最極端的交付方式是在每個(gè) feature 合并之后。

因此，CD，讓 CI 走得更遠(yuǎn)一步。在每個(gè) feature 合并到主線中，軟件不僅要測(cè)試正確性，而且也要包裝和部署到測(cè)試環(huán)境（比較理想地符合生產(chǎn)環(huán)境）。所有這一切都是以完全自動(dòng)化的方式。注意，上圖中缺少的草圖 (表示手動(dòng)步驟)。

還要注意，每個(gè) feature 都是推送到生產(chǎn)的潛在候選者。不是所有候選人都會(huì)被發(fā)送到生產(chǎn)。根據(jù)組織，部署到生產(chǎn)的決定需要人工干預(yù)，人類只決定一個(gè) release 是否應(yīng)該發(fā)送到生產(chǎn)（但不會(huì)準(zhǔn)備這個(gè) release 本身）。這個(gè) release 在測(cè)試環(huán)境已經(jīng)被打包，測(cè)試和部署。

持續(xù)交付比持續(xù)集成更難采用。其原因是因?yàn)槊總€(gè)發(fā)布候選者都有可能達(dá)到生產(chǎn)，因此需要自動(dòng)化整個(gè)生命周期：

• 構(gòu)建應(yīng)該是可重復(fù)性和確定性的。
• 所有 release 步驟應(yīng)該都是自動(dòng)化的（它比聽起來更難）。
• 所有的配置和關(guān)聯(lián)的文件都應(yīng)該存在于代碼控制中 (而不僅僅是源代碼)。
• 每個(gè) feature / release 都應(yīng)該在它的測(cè)試環(huán)境中被測(cè)試過（以動(dòng)態(tài)方式創(chuàng)建和銷毀的理想方法）。
• 所有測(cè)試套件都應(yīng)自動(dòng)化且相對(duì)快速（它也是比聽起來更難）。

雖然云當(dāng)然可以幫助滿足所有這些要求，但在軟件團(tuán)隊(duì) (開發(fā)人員和運(yùn)營(yíng)部門) 中需要一定程度的紀(jì)律，以便真正擁抱持續(xù)交付。

一旦 CD 落地，發(fā)布會(huì)變得微不足道，因?yàn)樗鼈兛梢园磦€(gè)按鈕就能執(zhí)行。每個(gè)人（不僅僅是項(xiàng)目經(jīng)理）都具有 release candidate （譯者：release 候選版本，以下對(duì)此術(shù)語不做翻譯）的可見性。當(dāng)前的 release candidate 可能沒有所有請(qǐng)求的功能，或者說它可能無法滿足所有的要求，但是這對(duì)于發(fā)布過程來說并不重要。重要的其實(shí)是這個(gè) release 是完整測(cè)試和打包的，準(zhǔn)備就緒發(fā)送到生產(chǎn)（如果需要）。任何項(xiàng)目的相關(guān)人員可以給出綠燈并立即把 release 部署到生產(chǎn)。

如果你使用 CD，則軟件的生命周期可以概括成如下：

每個(gè) release candidate 都是預(yù)先預(yù)備好的。一個(gè)人決定是否一個(gè) release candidate 版本是否推送到生產(chǎn)。沒有推送到生產(chǎn)的 Release Candidate 仍然會(huì)作為一個(gè) artifact 儲(chǔ)存起來，如果將來有需要可以進(jìn)行召回。

就像持續(xù)集成一樣，如果你想知道更多的細(xì)節(jié)，這里有整本圍繞持續(xù)交付的書籍。

額外獎(jiǎng)勵(lì)：持續(xù)部署

CD 中的 “D” 也可以表示部署（Deployment）。這種開發(fā)方法建立在持續(xù)交付上, 基本上完全消除了所有人類干預(yù)。任何被發(fā)現(xiàn)準(zhǔn)備就緒的 release candidate （并且通過所有質(zhì)量測(cè)試）都會(huì)立即推送到生產(chǎn)。

不可否認(rèn)的是，只有極少數(shù)的公司可以這樣做。沒有人類干預(yù)直接推送到生產(chǎn)應(yīng)該不能掉以輕心。在撰寫這篇文章時(shí)，許多公司甚至都沒有實(shí)踐持續(xù)交付，更別說部署了。現(xiàn)在應(yīng)該清楚的是，每種開發(fā)方法都需要建立在之前那些基礎(chǔ)之上。

在向上移動(dòng)之前（譯者：按上圖向上移動(dòng)），你的組織應(yīng)該確保每個(gè)基礎(chǔ)都是真正穩(wěn)固的。在 Codefresh，我們已經(jīng)看到了很多公司試圖進(jìn)入云時(shí)代，在他們沒有真正的理解 CI/CD 管道時(shí)試圖硬塞進(jìn)現(xiàn)有的做法（為數(shù)據(jù)中心進(jìn)行優(yōu)化），并且其中一些做法現(xiàn)在已經(jīng)過時(shí)。嘗試采用持續(xù)部署而不完全擁抱持續(xù)交付是一場(chǎng)失敗的戰(zhàn)役。

另一種方法是查看這些方法涵蓋的內(nèi)容以及 CD 需要 CI 的方式,，如下圖所示：

請(qǐng)確保以正確的順序處理每個(gè)開發(fā)模式。針對(duì)持續(xù)交付是一個(gè)更現(xiàn)實(shí)的目標(biāo)，可選的工具也很豐富。

• 譯者：@wangjie
• 譯文：https://blog.wangjiegulu.com/2018/09/10/understanding-the-difference-between-ci-and-cd/
• 作者：@Kostis Kapelonis
• 原文：https://thenewstack.io/understanding-the-difference-between-ci-and-cd/