[[406218]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Docker映像對于分布式、模塊化和微服務(wù)軟件部署變得越來越重要。如果組織的持續(xù)集成(CI)/持續(xù)交付(CD)工具知道如何處理Docker映像，包括從源代碼、二進(jìn)制文件和先決條件創(chuàng)建鏡像，以及將映像部署到特定環(huán)境，那么將會有很大幫助。如果沒有這個功能，組織可能需要編寫插件或腳本來實(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)工具具有不同級別的支持和文檔。對于其他產(chǎn)品，組織可能需要調(diào)查文檔和支持論壇以及付費(fèi)支持選項，作為組織在選擇工具時盡職調(diào)查的一部分。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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