如何選擇基於雲端計算的持續整合(CI)/持續交付(CD)平臺

在雲平臺中託管持續整合(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)管道連線到生產例項之前，需要確保練習測試套件和回滾功能，並讓組織的員工參與其中，直到非常確定其自動化可靠為止。