[[406218]]

【51CTO.com快譯】在云平臺(tái)中托管持續(xù)集成(CI)/持續(xù)交付(CD)，既能加快開(kāi)發(fā)管道和源代碼存儲(chǔ)庫(kù)之間的交互，又能讓開(kāi)發(fā)人員的工作更輕松。

如果組織的目標(biāo)是加快軟件開(kāi)發(fā)過(guò)程或?qū)⒐ぷ鳂?gòu)建頻繁交付到生產(chǎn)環(huán)境，則需要實(shí)現(xiàn)測(cè)試和交付過(guò)程的自動(dòng)化。在理想情況下，這意味著組織為其項(xiàng)目構(gòu)建持續(xù)集成(CI)/持續(xù)交付(CD)管道，在客戶使用其軟件之前捕獲錯(cuò)誤的測(cè)試套件，以及實(shí)現(xiàn)構(gòu)建管道步驟的腳本。

持續(xù)集成(CI)是以一致的方式使軟件構(gòu)建、打包和測(cè)試實(shí)現(xiàn)自動(dòng)化的一種方法。持續(xù)集成(CI)有助于讓開(kāi)發(fā)團(tuán)隊(duì)確定他們檢查到的源代碼版本控制中的更改不會(huì)破壞構(gòu)建軟件或?qū)㈠e(cuò)誤引入軟件。持續(xù)集成(CI)的端點(diǎn)通常是對(duì)軟件存儲(chǔ)庫(kù)主分支的完整簽入。

持續(xù)交付(CD)自動(dòng)將經(jīng)過(guò)測(cè)試的軟件交付到基礎(chǔ)設(shè)施環(huán)境，但這并不意味著將其直接投入生產(chǎn)。在通常情況下，組織首先將構(gòu)建的軟件推送到開(kāi)發(fā)環(huán)境。在開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)并發(fā)布新版本后，通常會(huì)進(jìn)入一個(gè)測(cè)試環(huán)境，在那里它被更廣泛的用戶群體使用(有時(shí)只是專門(mén)的內(nèi)部測(cè)試人員進(jìn)行測(cè)試，有時(shí)讓用戶注冊(cè)了beta版本進(jìn)行測(cè)試)并密切監(jiān)控。最后，如果一切順利的話，測(cè)試人員會(huì)確認(rèn)并將新版本的軟件推送到生產(chǎn)環(huán)境。

在持續(xù)交付(CD)過(guò)程的每個(gè)階段，都有一些選項(xiàng)可以快速恢復(fù)到舊版本并生成錯(cuò)誤報(bào)告，以供開(kāi)發(fā)人員在新版本中解決這些錯(cuò)誤。其目標(biāo)不是將大量構(gòu)建投入生產(chǎn)，而是在不引入回歸的情況下不斷改進(jìn)和增強(qiáng)軟件。而開(kāi)展這些實(shí)踐的另一個(gè)術(shù)語(yǔ)是“DevOps”。

為什么要在云中托管持續(xù)集成(CI)/持續(xù)交付(CD)?

組織在自己的數(shù)據(jù)中心托管持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)是一個(gè)可行的選擇，特別是對(duì)于要求在防火墻內(nèi)托管其應(yīng)用程序和數(shù)據(jù)的組織來(lái)說(shuō)更是如此。這樣做的缺點(diǎn)是組織需要有專門(mén)的團(tuán)隊(duì)來(lái)維護(hù)基礎(chǔ)設(shè)施，并且將承擔(dān)采購(gòu)和運(yùn)營(yíng)服務(wù)器的資本支出。

如果允許在云中托管，這通常是更好的選擇。云平臺(tái)托管的成本適中，其運(yùn)營(yíng)費(fèi)用可以由提供的服務(wù)抵消：入職、基礎(chǔ)設(shè)施維護(hù)、安全維護(hù)、支持和持續(xù)集成(CI)/持續(xù)交付(CD)軟件維護(hù)。而在云中托管持續(xù)集成(CI)/持續(xù)交付(CD)軟件通常會(huì)使管道與源代碼存儲(chǔ)庫(kù)交互更容易、更快。如果組織的開(kāi)發(fā)人員和測(cè)試人員分布在不同的地理位置，與在防火墻后面的遠(yuǎn)程服務(wù)器中托管相比，在云中托管存儲(chǔ)庫(kù)通常會(huì)給開(kāi)發(fā)人員帶來(lái)更好的體驗(yàn)。

組織還可以在內(nèi)部部署設(shè)施和云平臺(tái)的混合部署方案中持續(xù)集成(CI)/持續(xù)交付(CD)。一些最新的持續(xù)集成(CI)/持續(xù)交付(CD)產(chǎn)品在Kubernetes集群上的容器中運(yùn)行，這些集群在內(nèi)部部署設(shè)施和云平臺(tái)中運(yùn)行同樣令人滿意。而在混合部署方案中，組織可以將每個(gè)組件放置在考慮到開(kāi)發(fā)人員本身的物理位置以及開(kāi)發(fā)基礎(chǔ)設(shè)施中其他服務(wù)器的網(wǎng)絡(luò)位置最有意義的位置。

持續(xù)集成(CI)/持續(xù)交付(CD)必須與組織的存儲(chǔ)庫(kù)集成

存儲(chǔ)庫(kù)對(duì)于持續(xù)集成(CI)/持續(xù)交付(CD)至關(guān)重要。除了作為簽入和測(cè)試過(guò)程的終點(diǎn)之外，軟件存儲(chǔ)庫(kù)還是存儲(chǔ)持續(xù)集成(CI)/持續(xù)交付(CD)腳本和配置文件的首選位置。許多持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)可以在內(nèi)部存儲(chǔ)腳本和其他文件，但最好將它們置于工具之外的版本控制中。

幾乎所有持續(xù)集成(CI)/持續(xù)交付(CD)工具都可以與Git交互。有些還直接與GitHub、GitHub Enterprise、GitLab和Bitbucket集成，一些還支持Subversion和Mercurial。

組織的持續(xù)集成(CI)/持續(xù)交付(CD)工具需要支持編程語(yǔ)言和工具

每個(gè)編程語(yǔ)言或語(yǔ)言組(JVM語(yǔ)言、LLVM編譯語(yǔ)言、.NET語(yǔ)言等)往往都有自己的構(gòu)建工具和測(cè)試工具。因此，持續(xù)集成(CI)/持續(xù)交付(CD)工具必須支持作為給定項(xiàng)目一部分的所有語(yǔ)言。否則，組織可能需要為該工具編寫(xiě)一個(gè)或多個(gè)插件。

Docker映像對(duì)于分布式、模塊化和微服務(wù)軟件部署變得越來(lái)越重要。如果組織的持續(xù)集成(CI)/持續(xù)交付(CD)工具知道如何處理Docker映像，包括從源代碼、二進(jìn)制文件和先決條件創(chuàng)建鏡像，以及將映像部署到特定環(huán)境，那么將會(huì)有很大幫助。如果沒(méi)有這個(gè)功能，組織可能需要編寫(xiě)插件或腳本來(lái)實(shí)現(xiàn)需要的Docker功能。而組織希望持續(xù)集成(CI)/持續(xù)交付(CD)工具支持Kubernetes和在環(huán)境中使用的任何其他容器編排系統(tǒng)。

開(kāi)發(fā)人員是否了解持續(xù)集成(CI)/持續(xù)交付(CD)和組織正在考慮的工具?

持續(xù)集成(CI)/持續(xù)交付(CD)的原則似乎很明顯，但細(xì)節(jié)卻并非如此。各種持續(xù)集成(CI)/持續(xù)交付(CD)工具具有不同級(jí)別的支持和文檔。對(duì)于其他產(chǎn)品，組織可能需要調(diào)查文檔和支持論壇以及付費(fèi)支持選項(xiàng)，作為組織在選擇工具時(shí)盡職調(diào)查的一部分。

組織不要假設(shè)一個(gè)平臺(tái)對(duì)于其所有軟件開(kāi)發(fā)項(xiàng)目都是最佳的。大多數(shù)組織使用多種編程語(yǔ)言和環(huán)境，并不是每個(gè)持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)都能很好地支持這些語(yǔ)言和環(huán)境。

組織需要選擇最適合其每個(gè)項(xiàng)目的持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)，而不是尋找一個(gè)折衷的平臺(tái)。持續(xù)集成(CI)/持續(xù)交付(CD)的原則是從一個(gè)平臺(tái)轉(zhuǎn)移到另一個(gè)平臺(tái)，即使組織為它們編寫(xiě)的腳本并不總是可移植的。雖然了解和熟悉每個(gè)新平臺(tái)可能會(huì)讓組織的DevOps團(tuán)隊(duì)花費(fèi)一些時(shí)間，但這很可能比需要廣泛定制持續(xù)集成(CI)/持續(xù)交付(CD)工具的成本更低。

規(guī)劃未來(lái)的持續(xù)集成(CI)/持續(xù)交付(CD)遷移

同樣，組織不要假設(shè)給定的持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)將會(huì)一直滿足其項(xiàng)目需求。例如通過(guò)將腳本存儲(chǔ)在存儲(chǔ)庫(kù)中而不是在持續(xù)集成(CI)/持續(xù)交付(CD)工具中。

在適當(dāng)?shù)那闆r下首選無(wú)服務(wù)器持續(xù)集成(CI)/持續(xù)交付(CD)

一般來(lái)說(shuō)，容器部署比云計(jì)算服務(wù)器實(shí)例部署成本更低，無(wú)服務(wù)器的云部署比容器部署成本更低。如今，很少有持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)可以通過(guò)無(wú)服務(wù)器運(yùn)行。

無(wú)服務(wù)器意味著運(yùn)行感興趣的進(jìn)程的容器在必要時(shí)被實(shí)例化，通常只是為了響應(yīng)一個(gè)事件。對(duì)于持續(xù)集成(CI)/持續(xù)交付(CD)，其觸發(fā)事件一般是代碼簽入到特定的存儲(chǔ)庫(kù)分支;然后存儲(chǔ)庫(kù)Webhook啟動(dòng)無(wú)服務(wù)器進(jìn)程。當(dāng)該過(guò)程完成時(shí)，這些資源被釋放。

少數(shù)可以運(yùn)行無(wú)服務(wù)器的持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)之一是Serverless CI/CD，它是Serverless Framework的增強(qiáng)版本。Serverless CI/CD針對(duì)部署無(wú)服務(wù)器應(yīng)用程序進(jìn)行了優(yōu)化，目前僅在AWS云平臺(tái)上運(yùn)行。組織在使用時(shí)必須確定它是否足夠支持其應(yīng)用程序以供使用。

企業(yè)當(dāng)前的云計(jì)算資產(chǎn)在哪里?

為了優(yōu)化基于云計(jì)算的持續(xù)集成(CI)/持續(xù)交付(CD)配置，如果組織所有資產(chǎn)彼此“接近”會(huì)有所幫助。而“接近”是指地理位置彼此接近或者指的是網(wǎng)絡(luò)位置彼此接近。

例如，如果組織的數(shù)據(jù)庫(kù)存儲(chǔ)在澳大利亞而應(yīng)用程序在北美地區(qū)，那么每次應(yīng)用程序需要讀取或?qū)懭霐?shù)據(jù)時(shí)，可能會(huì)有很大的延遲。在較小的范圍內(nèi)，如果組織的應(yīng)用程序和數(shù)據(jù)庫(kù)在同一個(gè)云平臺(tái)的可用性區(qū)域(AZ)中，它們之間的延遲將被最小化。如果是在同一地域的不同的可用性區(qū)域(AZ)，其延遲會(huì)增加，但不會(huì)像在不同地域那樣高。

同樣，如果組織的數(shù)據(jù)庫(kù)位于弗吉尼亞州的谷歌云平臺(tái)上，而其應(yīng)用程序位于弗吉尼亞州的Microsoft Azure云平臺(tái)上，則延遲將高于數(shù)據(jù)庫(kù)和應(yīng)用程序位于同一可用性區(qū)域的同一云平臺(tái)上的延遲。所有這些也適用于組織的存儲(chǔ)庫(kù)、持續(xù)集成(CI)/持續(xù)交付(CD)軟件、實(shí)際應(yīng)用程序，以及開(kāi)發(fā)人員和測(cè)試人員。如果所有這些彼此“接近”會(huì)有所幫助，盡管在這種情況下延遲的影響并不像實(shí)時(shí)互動(dòng)游戲那樣明顯。

如果開(kāi)發(fā)人員能夠可靠地將代碼提交推送到主存儲(chǔ)庫(kù)，并且沒(méi)有明顯的延遲，他們通常會(huì)有良好的體驗(yàn)。同樣，如果用戶和測(cè)試人員“接近”應(yīng)用程序以獲得亞秒級(jí)響應(yīng)時(shí)間，他們也是如此。對(duì)于持續(xù)集成(CI)/持續(xù)交付(CD)軟件，關(guān)鍵是與部署點(diǎn)的可靠連接。只要不導(dǎo)致超時(shí)或丟包，有一點(diǎn)延遲是可以容忍的，

一旦完全實(shí)施持續(xù)集成(CI)/持續(xù)交付(CD)，它就會(huì)成為基礎(chǔ)設(shè)施的重要組成部分。在組織加快實(shí)施時(shí)需要記住這一點(diǎn)。

在開(kāi)始推出持續(xù)集成(CI)/持續(xù)交付(CD)管道之前執(zhí)行嚴(yán)格的概念驗(yàn)證非常重要。在開(kāi)始持續(xù)交付(CD)階段之前，先要處理好持續(xù)集成(CI)部分。在將任何持續(xù)集成(CI)/持續(xù)交付(CD)管道連接到生產(chǎn)實(shí)例之前，需要確保練習(xí)測(cè)試套件和回滾功能，并讓組織的員工參與其中，直到非常確定其自動(dòng)化可靠為止。

原文標(biāo)題：How to choose a cloud-based CI/CD platform，作者：Martin Heller

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】