[[406218]]

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

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

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

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

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

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

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

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

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

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

存儲庫對于持續(xù)集成(CI)/持續(xù)交付(CD)至關重要。除了作為簽入和測試過程的終點之外，軟件存儲庫還是存儲持續(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語言等)往往都有自己的構建工具和測試工具。因此，持續(xù)集成(CI)/持續(xù)交付(CD)工具必須支持作為給定項目一部分的所有語言。否則，組織可能需要為該工具編寫一個或多個插件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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