如何選擇基于云的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 的端點通常是對軟件存儲庫的主分支的完整簽入”時可能已經收集到的那樣，存儲庫對于 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 工具具有不同級別的支持和文檔。有很多關于 Jenkins 的書，這并不奇怪，因為它是最古老的書。
對于其他產品，你可能需要調查文檔和支持論壇以及付費支持選項，作為你在選擇工具時盡職調查的一部分。
關于CI的一般背景，請考慮Addison-Wesley的書《持續集成》(Continuous Integration)，作者是Duvall等人。同樣，對于CD的一般背景，可以參考Humble和Farley的Continuous Delivery。兩本書出版時都獲得了Jolt獎。
你可以為不同的項目選擇不同的 CI/CD 工具
雖然本指南是關于選擇 CI/CD 平臺的，但請不要假設一個平臺對于你的所有軟件開發項目都是最佳的。大多數商店使用多種編程語言和環境，并不是每個 CI/CD 平臺都能很好地支持所有這些。
隨意選擇最適合你的每個項目的 CI/CD 平臺，而不是尋找一個折衷的平臺。CI 和 CD 的一般原則從一個平臺轉移到另一個平臺，即使你為它們編寫的腳本可能并不總是可移植的。
雖然每個新平臺的額外入門時間可能會讓你的 DevOps 團隊花費一些時間，但這很可能比需要廣泛定制 CI/CD 工具更便宜。
規劃未來的 CI/CD 遷移
同樣，請不要假設給定的 CI/CD 平臺將永遠滿足你的項目需求。始終對沖你的賭注，例如通過將腳本存儲在存儲庫中而不是在 CI/CD 工具中。
在適當的情況下首選無服務器serverless CI/CD
一般來說，云容器部署比云服務器實例部署便宜，無服務器云部署比容器部署便宜。 不幸的是，在撰寫本文時，很少有 CI/CD 平臺可以無服務器運行。
無服務器意味著運行感興趣的進程的容器在必要時被實例化，通常是為了響應一個事件。 對于 CI/CD，觸發事件一般是代碼簽入到特定的存儲庫分支;然后存儲庫 Webhook 啟動無服務器進程。當該過程完成時，資源被釋放。
少數可以運行無服務器的 CI/CD 平臺之一是無服務器 CI/CD，它是無服務器框架 Pro 的一部分，是開源無服務器框架的增強版本。無服務器 CI/CD 針對部署無服務器應用程序進行了優化，目前僅在 AWS 上運行。你必須確定它是否足夠支持你的應用程序以供使用。
在提交之前做一個概念證明
一旦完全實施 CI/CD，它就會成為基礎設施的重要組成部分。在你加快速度時請記住這一點。
在開始推出 CI/CD 管道之前執行嚴格的概念驗證非常重要。在開始 CD 階段之前，先將 CI 部分放下。在將任何 CI/CD 管道連接到生產實例之前，請確保練習測試套件和回滾功能，并讓人工參與其中，直到你非常確定自動化堅如磐石。
原文鏈接：https://www.infoworld.com/article/3620932/how-to-choose-a-cloud-based-cicd-platform.html
