[[406218]]

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

如果組織的目標是加快軟件開發過程或將工作構建頻繁交付到生產環境，則需要實現測試和交付過程的自動化。在理想情況下，這意味著組織為其項目構建持續集成(CI)/持續交付(CD)管道，在客戶使用其軟件之前捕獲錯誤的測試套件，以及實現構建管道步驟的腳本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在適當的情況下首選無服務器持續集成(CI)/持續交付(CD)

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

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

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

企業當前的云計算資產在哪里?

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

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

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

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

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

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

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

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