[[406218]]

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

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

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

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

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

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

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

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

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

存儲(chǔ)庫對(duì)于持續(xù)集成(CI)/持續(xù)交付(CD)至關(guān)重要。除了作為簽入和測試過程的終點(diǎn)之外，軟件存儲(chǔ)庫還是存儲(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)工具需要支持編程語言和工具

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

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

開發(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ì)于其所有軟件開發(fā)項(xiàng)目都是最佳的。大多數(shù)組織使用多種編程語言和環(huán)境，并不是每個(gè)持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)都能很好地支持這些語言和環(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)，即使組織為它們編寫的腳本并不總是可移植的。雖然了解和熟悉每個(gè)新平臺(tái)可能會(huì)讓組織的DevOps團(tuán)隊(duì)花費(fèi)一些時(shí)間，但這很可能比需要廣泛定制持續(xù)集成(CI)/持續(xù)交付(CD)工具的成本更低。

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

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

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

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

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

少數(shù)可以運(yùn)行無服務(wù)器的持續(xù)集成(CI)/持續(xù)交付(CD)平臺(tái)之一是Serverless CI/CD，它是Serverless Framework的增強(qiáng)版本。Serverless CI/CD針對(duì)部署無服務(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ù)庫存儲(chǔ)在澳大利亞而應(yīng)用程序在北美地區(qū)，那么每次應(yīng)用程序需要讀取或?qū)懭霐?shù)據(jù)時(shí)，可能會(huì)有很大的延遲。在較小的范圍內(nèi)，如果組織的應(yīng)用程序和數(shù)據(jù)庫在同一個(gè)云平臺(tái)的可用性區(qū)域(AZ)中，它們之間的延遲將被最小化。如果是在同一地域的不同的可用性區(qū)域(AZ)，其延遲會(huì)增加，但不會(huì)像在不同地域那樣高。

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

如果開發(fā)人員能夠可靠地將代碼提交推送到主存儲(chǔ)庫，并且沒有明顯的延遲，他們通常會(huì)有良好的體驗(yàn)。同樣，如果用戶和測試人員“接近”應(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)。

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

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

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