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

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

作者：貓神。

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

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

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

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

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

投入：

需要為每個新特性編寫測試用例

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

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

產(chǎn)出：

更少的 bug，因為自動化測試可以回歸測試產(chǎn)品

編譯部署產(chǎn)品更簡化，因為集成的問題都盡早的解決了

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

測試成本降低，因為 CI 服務(wù)器可以一秒運行幾百個測試用例

測試團隊花更少的時間測試，可以重點關(guān)注測試上的改進。

投入：

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

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

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

部署軟件變得非常簡單。團隊不需要花費 n 天準備發(fā)布。

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

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

投入：

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

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

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

快速的發(fā)布節(jié)奏，因為每個新特性一旦完成都會自動的發(fā)布給用戶。

發(fā)布風(fēng)險降低，修復(fù)問題更容易，因為每次變更都是小步迭代發(fā)布。

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

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

如果正在開發(fā)的是一個老系統(tǒng)，就需要放慢節(jié)奏，開始打造持續(xù)集成&持續(xù)交付。首先可以完成一些簡單可自動化執(zhí)行的單元測試，不需要考慮復(fù)雜的端到端的測試。另外，應(yīng)該盡快嘗試自動化部署，搭建可以自動化部署的臨時環(huán)境。因為自動化部署，可以讓開發(fā)者去優(yōu)化測試用例，而不是停下來聯(lián)調(diào)發(fā)布。
一旦開始按日發(fā)布產(chǎn)品，我們可以考慮持續(xù)部署，但一定要保證團隊已經(jīng)準備好這種方式，文檔 & 售后支持 & 市場。這些步驟都需要加入到新產(chǎn)品發(fā)布節(jié)奏中，因為和用戶直接打交道的是他們。

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

單元測試：范圍非常小，驗證每個獨立方法級別的操作。

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

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

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

并不是所有的測試都是對等的，實際運行中可以做些取舍。

單元測試實現(xiàn)起來既快成本又低，因為它們主要是對小代碼塊進行檢查。另一方面，UI 測試實施起來很復(fù)雜，運行起來很慢，因為它們通常需要啟動一個完整的環(huán)境以及多個服務(wù)來模擬瀏覽器或移動行為。因此，實際情況可能希望限制復(fù)雜的 UI 測試的數(shù)量，并依賴基礎(chǔ)上良好的單元測試來快速構(gòu)建，并盡快獲得開發(fā)人員的反饋。

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

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

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

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

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

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

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

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

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

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

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

修 bug 的時候編寫測試用例。把 bug 的每個場景都編寫成測試用例，避免再次出現(xiàn)。

從最嚴格的代碼部分入手測試

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

確保團隊成員每天合并變更

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

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

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

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

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

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

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