摘要：持續(xù)交付持續(xù)交付是持續(xù)集成的擴(kuò)展，可以保證穩(wěn)定的發(fā)布產(chǎn)品新特性。持續(xù)部署持續(xù)部署是持續(xù)交付的下一步。持續(xù)部署可以加速用戶反饋新特性，避免發(fā)布日帶來的壓力。單元測(cè)試范圍非常小，驗(yàn)證每個(gè)獨(dú)立方法級(jí)別的操作。

相信大家以前應(yīng)該接觸過持續(xù)集成（Continuous integration）持續(xù)交付（continuous delivery）持續(xù)發(fā)布（continuous deployment）的概念，下面我們來說說三者的差異以及團(tuán)隊(duì)如何入手 CI/CD。

作者：貓神。

開發(fā)者盡量時(shí)時(shí)刻刻合并開發(fā)分支至主干分支。避免直到發(fā)布日才開始合并，掉入集成地獄。無論何時(shí)新分支集成至項(xiàng)目，持續(xù)集成可以自動(dòng)化測(cè)試持續(xù)驗(yàn)證應(yīng)用是否正常。

持續(xù)交付是持續(xù)集成的擴(kuò)展，可以保證穩(wěn)定的發(fā)布產(chǎn)品新特性。這意味著基于自動(dòng)化測(cè)試，你可以也可以一鍵自動(dòng)化發(fā)布。理論上，持續(xù)交付可以決定是按天，按周，按雙周發(fā)布產(chǎn)品。如果確實(shí)希望能夠享受持續(xù)交付的好處，那么應(yīng)該盡快發(fā)布到新產(chǎn)品中。一旦出現(xiàn)問題時(shí)能盡早排除。

持續(xù)部署是持續(xù)交付的下一步。通過這一步，每個(gè)新特性都自動(dòng)的部署到產(chǎn)品中。但是如果出現(xiàn)未通過的測(cè)試用例將會(huì)終止自動(dòng)部署。持續(xù)部署可以加速用戶反饋新特性，避免發(fā)布日帶來的壓力。開發(fā)可以著力于開發(fā)系統(tǒng)，開發(fā)結(jié)束后幾分鐘就可以觸達(dá)到用戶。

CI/CD 具體是個(gè)什么樣的流程呢，如下圖所示，差異僅在于是否自動(dòng)部署。

現(xiàn)在開發(fā)都講究投入產(chǎn)出比，那么 CI/CD 具體需要做些什么呢？

投入：

需要為每個(gè)新特性編寫測(cè)試用例

需要搭建持續(xù)集成服務(wù)器，監(jiān)控主干倉(cāng)庫(kù)，并自動(dòng)運(yùn)行測(cè)試用例

開發(fā)需要盡量頻繁的合并分支，至少一天一次

產(chǎn)出：

更少的 bug，因?yàn)樽詣?dòng)化測(cè)試可以回歸測(cè)試產(chǎn)品

編譯部署產(chǎn)品更簡(jiǎn)化，因?yàn)榧傻膯栴}都盡早的解決了

開發(fā)者可以盡量減少上下文切換，因?yàn)闃?gòu)建的時(shí)候就暴露問題，盡早解決了

測(cè)試成本降低，因?yàn)?CI 服務(wù)器可以一秒運(yùn)行幾百個(gè)測(cè)試用例

測(cè)試團(tuán)隊(duì)花更少的時(shí)間測(cè)試，可以重點(diǎn)關(guān)注測(cè)試上的改進(jìn)。

投入：

需要有持續(xù)集成的基礎(chǔ)，測(cè)試用例需要覆蓋足夠的代碼

部署需要自動(dòng)化，用戶只需要手動(dòng)觸發(fā)，剩余的部署應(yīng)該自動(dòng)化

團(tuán)隊(duì)需要增加新特性標(biāo)志，避免未完成的新特性進(jìn)入待發(fā)布的產(chǎn)品
產(chǎn)出：

部署軟件變得非常簡(jiǎn)單。團(tuán)隊(duì)不需要花費(fèi) n 天準(zhǔn)備發(fā)布。

可以提高發(fā)布頻率，加速新特性觸達(dá)用戶進(jìn)程。

小的更改，對(duì)決策的壓力要小得多，可以更快地迭代。

投入：

測(cè)試必須要做到足夠。測(cè)試的質(zhì)量將決定發(fā)布的質(zhì)量。

文檔建設(shè)需要和產(chǎn)品部署保持同步。

新特性的發(fā)布需要協(xié)調(diào)其他部門，包括售后支持&市場(chǎng)&推廣等。
產(chǎn)出：

快速的發(fā)布節(jié)奏，因?yàn)槊總€(gè)新特性一旦完成都會(huì)自動(dòng)的發(fā)布給用戶。

發(fā)布風(fēng)險(xiǎn)降低，修復(fù)問題更容易，因?yàn)槊看巫兏际切〔降l(fā)布。

用戶可以看到持續(xù)性的優(yōu)化和質(zhì)量提升，而不是非要等到按月，按季度，甚至按年

如果開發(fā)的是一個(gè)新項(xiàng)目，暫時(shí)還沒有任何用戶，那么每次提交代碼后發(fā)布將會(huì)特別簡(jiǎn)單，可以隨時(shí)隨地發(fā)布。一旦產(chǎn)品開始開發(fā)后，就需要提高測(cè)試文化，并確保在構(gòu)建應(yīng)用程序時(shí)增加代碼覆蓋率。當(dāng)您準(zhǔn)備好面向用戶發(fā)布時(shí)，您將有一個(gè)非常好的連續(xù)部署過程，在該過程中，所有新的更改都將在自動(dòng)發(fā)布到生產(chǎn)環(huán)境之前進(jìn)行測(cè)試。

如果正在開發(fā)的是一個(gè)老系統(tǒng)，就需要放慢節(jié)奏，開始打造持續(xù)集成&持續(xù)交付。首先可以完成一些簡(jiǎn)單可自動(dòng)化執(zhí)行的單元測(cè)試，不需要考慮復(fù)雜的端到端的測(cè)試。另外，應(yīng)該盡快嘗試自動(dòng)化部署，搭建可以自動(dòng)化部署的臨時(shí)環(huán)境。因?yàn)樽詣?dòng)化部署，可以讓開發(fā)者去優(yōu)化測(cè)試用例，而不是停下來聯(lián)調(diào)發(fā)布。
一旦開始按日發(fā)布產(chǎn)品，我們可以考慮持續(xù)部署，但一定要保證團(tuán)隊(duì)已經(jīng)準(zhǔn)備好這種方式，文檔 & 售后支持 & 市場(chǎng)。這些步驟都需要加入到新產(chǎn)品發(fā)布節(jié)奏中，因?yàn)楹陀脩糁苯哟蚪坏赖氖撬麄儭?/p> 四、如何開始持續(xù)集成 4.1 了解測(cè)試類型

為了獲得 CI 的所有好處，每次代碼變更后，我們需要自動(dòng)運(yùn)行測(cè)試用例。我們需要在每個(gè)分支運(yùn)行測(cè)試用例，而不是僅僅在主干分支。這樣可以最快速的找到問題，最小化問題影響面。
在初始階段并不需要實(shí)現(xiàn)所有的測(cè)試類型。一開始可以以單元測(cè)試入手，隨著時(shí)間擴(kuò)展覆蓋面。

單元測(cè)試：范圍非常小，驗(yàn)證每個(gè)獨(dú)立方法級(jí)別的操作。

集成測(cè)試：保證模塊間運(yùn)行正常，包括多個(gè)模塊、多個(gè)服務(wù)。

驗(yàn)收測(cè)試：與集成測(cè)試類似，但是僅關(guān)注業(yè)務(wù) case，而不是模塊內(nèi)部本身。

UI 測(cè)試：從用戶的角度保證呈現(xiàn)正確運(yùn)行。

并不是所有的測(cè)試都是對(duì)等的，實(shí)際運(yùn)行中可以做些取舍。

單元測(cè)試實(shí)現(xiàn)起來既快成本又低，因?yàn)樗鼈冎饕菍?duì)小代碼塊進(jìn)行檢查。另一方面，UI 測(cè)試實(shí)施起來很復(fù)雜，運(yùn)行起來很慢，因?yàn)樗鼈兺ǔＰ枰獑?dòng)一個(gè)完整的環(huán)境以及多個(gè)服務(wù)來模擬瀏覽器或移動(dòng)行為。因此，實(shí)際情況可能希望限制復(fù)雜的 UI 測(cè)試的數(shù)量，并依賴基礎(chǔ)上良好的單元測(cè)試來快速構(gòu)建，并盡快獲得開發(fā)人員的反饋。

要采用持續(xù)集成，您需要對(duì)推回到主分支的每個(gè)變更運(yùn)行測(cè)試。要做到這一點(diǎn)，您需要有一個(gè)服務(wù)來監(jiān)視您的存儲(chǔ)庫(kù)，并聽取對(duì)代碼庫(kù)的新推送。您可以從企業(yè)預(yù)置型解決方案和云端解決方案中進(jìn)行選擇。您需要考慮以下因素來選擇服務(wù)器：

代碼托管在哪里？CI 服務(wù)可以訪問您的代碼庫(kù)嗎？您對(duì)代碼的生存位置有特殊的限制嗎？

應(yīng)用程序需要哪些操作系統(tǒng)和資源？應(yīng)用程序環(huán)境是否受支持？能安裝正確的依賴項(xiàng)來構(gòu)建和測(cè)試軟件嗎？

測(cè)試需要多少資源？一些云應(yīng)用程序可能對(duì)您可以使用的資源有限制。如果軟件消耗大量資源，可能希望將 CI 服務(wù)器宿主在防火墻后面。

團(tuán)隊(duì)中有多少開發(fā)人員？當(dāng)團(tuán)隊(duì)實(shí)踐 CI 時(shí)，每天都會(huì)將許多更改推回到主存儲(chǔ)庫(kù)中。對(duì)于開發(fā)人員來說，要獲得快速的反饋，您需要減少構(gòu)建的隊(duì)列時(shí)間，并且您需要使用能夠提供正確并發(fā)性的服務(wù)或服務(wù)器。
在過去，通常需要安裝一個(gè)獨(dú)立的 CI 服務(wù)器，如 Bamboo 或 Jenkins，但現(xiàn)在您可以在云端找到更簡(jiǎn)單的解決方案。例如，如果您的代碼托管在 BitBucket 云上，那么您可以使用存儲(chǔ)庫(kù)中的 Pipelines 功能在每次推送時(shí)運(yùn)行測(cè)試，而無需配置多帶帶的服務(wù)器或構(gòu)建代理，也無需限制并發(fā)性。

使用代碼覆蓋率查找未測(cè)試的代碼。一旦您采用了自動(dòng)化測(cè)試，最好將它與一個(gè)測(cè)試覆蓋工具結(jié)合起來，幫助了解測(cè)試套件覆蓋了多少代碼庫(kù)。代碼覆蓋率定在 80%以上是很好的，但要注意不要將高覆蓋率與良好的測(cè)試套件混淆。代碼覆蓋工具將幫助您找到未經(jīng)測(cè)試的代碼，但在一天結(jié)束的時(shí)候，測(cè)試的質(zhì)量會(huì)產(chǎn)生影響。如果剛開始，不要急于獲得代碼庫(kù)的 100%覆蓋率，而是使用測(cè)試覆蓋率工具來找出應(yīng)用程序的關(guān)鍵部分，這些部分還沒有測(cè)試并從那里開始。

重構(gòu)是一個(gè)添加測(cè)試的機(jī)會(huì)。如果您將要對(duì)應(yīng)用程序進(jìn)行重大更改，那么應(yīng)該首先圍繞可能受到影響的特性編寫驗(yàn)收測(cè)試。這將為您提供一個(gè)安全網(wǎng)，以確保在重構(gòu)代碼或添加新功能后，原始行為不會(huì)受到影響。

自動(dòng)化測(cè)試是 CI 的關(guān)鍵，但同時(shí)也需要團(tuán)隊(duì)成員接受 CI 文化，并不是心血來潮曬兩天魚，并且需要保證編譯暢通無阻。QA 可以幫助團(tuán)隊(duì)建設(shè)測(cè)試文化。他們不再需要手動(dòng)測(cè)試應(yīng)用程序的瑣碎功能，現(xiàn)在他們可以投入更多的時(shí)間來提供支持開發(fā)人員的工具，并幫助他們采用正確的測(cè)試策略。一旦開始采用持續(xù)集成，QA 工程師將能夠?qū)Ｗ⒂谑褂酶玫墓ぞ吆蛿?shù)據(jù)集促進(jìn)測(cè)試，并幫助開發(fā)人員提高編寫更好代碼的能力。

盡早集成。如果很長(zhǎng)時(shí)間不合并代碼，代碼沖突的風(fēng)險(xiǎn)就越高，代碼沖突的范圍就越廣。如果發(fā)現(xiàn)某些分支會(huì)影響已經(jīng)存在的分支，需要增加發(fā)布關(guān)閉標(biāo)簽，避免發(fā)布時(shí)兩個(gè)分支沖突。

保證編譯時(shí)時(shí)刻刻暢通。一旦發(fā)現(xiàn)任何編譯問題，立刻修復(fù)，否則可能會(huì)帶來更多的錯(cuò)誤。測(cè)試套件需要盡快反饋測(cè)試結(jié)果，或者優(yōu)先返回短時(shí)間測(cè)試（單元測(cè)試）的結(jié)果，否則開發(fā)者可能就切換回開發(fā)了。一旦編譯出錯(cuò)，需要通知給開發(fā)者，或者更進(jìn)一步給出一個(gè) dashboard，每個(gè)人都可以在這里查看編譯結(jié)果。

把測(cè)試用例納入流程的一部分。確保每個(gè)分支都有自動(dòng)化測(cè)試用例。似乎編寫測(cè)試用例拖慢了項(xiàng)目節(jié)奏，但是它可以減少回歸時(shí)間，減少每次迭代帶來的 bug。而且每次測(cè)試通過后，將會(huì)非常有信息合并到主干分支，因?yàn)樾略龅膬?nèi)容不影響以前的功能。

修 bug 的時(shí)候編寫測(cè)試用例。把 bug 的每個(gè)場(chǎng)景都編寫成測(cè)試用例，避免再次出現(xiàn)。

從最嚴(yán)格的代碼部分入手測(cè)試

搭建一個(gè)自動(dòng)構(gòu)建的服務(wù)自動(dòng)運(yùn)行測(cè)試用例，在每次提交代碼后。

確保團(tuán)隊(duì)成員每天合并變更

代碼出現(xiàn)問題及時(shí)修復(fù)

為每個(gè)新實(shí)現(xiàn)的操作編寫測(cè)試用例。
可能看著很簡(jiǎn)單，但是要求團(tuán)隊(duì)能夠真正落地。一開始你需要放慢發(fā)布的腳步，需要和 pd、用戶溝通確保不上線沒有測(cè)試用例的新功能。我們的建議是從小處入手，通過簡(jiǎn)單的測(cè)試來適應(yīng)新的例程，然后再著手實(shí)現(xiàn)更復(fù)雜更難管理的測(cè)試套件。

以上文章主要是說明團(tuán)隊(duì)實(shí)現(xiàn) CI/CD 的取舍和可行性步驟。下面來說說希望 CI/CD 給筆者團(tuán)隊(duì)帶來什么樣的變化。目前筆者團(tuán)隊(duì)已經(jīng)實(shí)現(xiàn)前端項(xiàng)目發(fā)布編譯工程化，采用的是基于 webpack 的自建工具云構(gòu)建模式。但現(xiàn)在面臨的問題是 1. 交互的系統(tǒng)比較多，交互系統(tǒng)提供的接入源變更后，需要人工通知其他系統(tǒng)手動(dòng)觸發(fā)編譯，而且每次手動(dòng)編譯都需要在本地切換到指定分支，然后手動(dòng)觸發(fā)云構(gòu)建，2. 多人協(xié)作，分支拆分較細(xì)，需要手動(dòng)合并分支，觸發(fā)編譯。整個(gè)流程冗長(zhǎng)，而且中間存在人力溝通成本，容易產(chǎn)生溝通誤差。所以首先希望解決的是 CI 自動(dòng)化，當(dāng)依賴變更后或者分支合并后，自動(dòng)集成，自動(dòng)編譯。當(dāng)然生產(chǎn)環(huán)境暫時(shí)還不敢瞎搞，但大部分重復(fù)編譯的工作量主要集中在預(yù)發(fā)環(huán)境，所以手動(dòng)部署生產(chǎn)環(huán)境的成本還是可以接受的。CI 自動(dòng)化之前，需要提供系統(tǒng)之間交互的單元測(cè)試用例，每次 CI 后自動(dòng)運(yùn)行單元測(cè)試用例，最好能打通 QA 的測(cè)試用例，進(jìn)行回歸測(cè)試。流程對(duì)比如下：

可以看出引入CI后，我們的成本是需要搭建CI服務(wù)器，新增單元測(cè)試、打通回歸測(cè)試案例，但前者可以加快系統(tǒng)編譯效率，后者可以進(jìn)一步的提升代碼質(zhì)量，減少回歸測(cè)試時(shí)間，這些成本都是可以接受的。市面上已有很多開源持續(xù)集成工具，例如我們熟悉的Jenkins，還有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。目前還在繼續(xù)調(diào)研中，這片文章應(yīng)該會(huì)有第二篇，說說后續(xù)的實(shí)踐和CD。

討論地址是：精讀《持續(xù)集成 vs 持續(xù)交付 vs 持續(xù)部署》 · Issue #147 · dt-fe/weekly

如果你想?yún)⑴c討論，請(qǐng) 點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。

關(guān)注 前端精讀微信公眾號(hào)