如何選擇基于云的CI/CD平臺?

在云中托管CI/CD既可以加快開(kāi)發(fā)管道和源代碼存儲庫之間的交互，也可以使開(kāi)發(fā)人員的工作更輕松。

在云中托管/既可以加快開(kāi)發(fā)管道和源代碼存儲庫之間的交互，也可以使開(kāi)發(fā)人員的工作更輕松。

如果你的目標是高速軟件開(kāi)發(fā)和將工作構建頻繁交付到生產(chǎn)環(huán)境，則你需要至少自動(dòng)化部分測試和交付過(guò)程。

理想情況下，這意味著(zhù)為你的項目實(shí)施 CI/CD 管道，以及在客戶(hù)看到軟件之前捕獲錯誤的測試套件，以及實(shí)現管道步驟的腳本。

持續集成 (CI) 是一種以一致的方式自動(dòng)化軟件構建、打包和測試的方法。CI 有助于讓團隊相信他們檢查到源代碼版本控制中的更改不會(huì )破壞構建或將錯誤引入軟件。

CI 的端點(diǎn)通常是對軟件存儲庫主分支的完整簽入。

持續交付 (CD) 自動(dòng)將經(jīng)過(guò)測試的軟件交付到基礎設施環(huán)境。這通常并不意味著(zhù)將其直接投入生產(chǎn)以查看客戶(hù)是否抱怨。

通常，組織首先將構建推送到開(kāi)發(fā)環(huán)境。在開(kāi)發(fā)人員自己擊敗并發(fā)布新版本后，它通常會(huì )進(jìn)入一個(gè)測試環(huán)境，在那里它被更廣泛的用戶(hù)群體使用(有時(shí)只是專(zhuān)門(mén)的內部測試人員，有時(shí)更多的用戶(hù)注冊了 beta 測試或“狗食”)并密切監控。

最后，如果一切順利，測試人員會(huì )簽字并將新版本推送到生產(chǎn)環(huán)境。

在 CD 的每個(gè)階段，都有選項可以快速恢復到舊版本并生成錯誤報告票供開(kāi)發(fā)人員在新版本中解決。目標不是將大量構建投入生產(chǎn)，而是在不引入回歸的情況下不斷改進(jìn)和增強軟件。這些實(shí)踐的另一個(gè)術(shù)語(yǔ)是“devops”。

為什么要在云中托管 CI/CD?

在你自己的數據中心托管 CI/CD 是一個(gè)可行的選擇，特別是對于要求在防火墻內托管其應用程序和數據的公司。這樣做的缺點(diǎn)是你需要一個(gè)專(zhuān)門(mén)的團隊來(lái)維護基礎設施，并且你將承擔一些服務(wù)器資本支出。

如果允許你在云中托管，通常是更好的選擇。在云中托管的成本適中，運營(yíng)費用由提供的服務(wù)抵消：入職、基礎設施維護、安全維護、支持和 CI/CD 軟件維護。在云中托管 CI/CD 軟件通常會(huì )使管道與源代碼存儲庫交互更容易、更快，如果它們也在云中。

如果你的開(kāi)發(fā)人員和測試人員分布在不同的地理位置，與在防火墻后面的遠程服務(wù)器中托管相比，在云中托管你的存儲庫通常會(huì )給開(kāi)發(fā)人員帶來(lái)更好的體驗。

還可以在本地和云服務(wù)器的混合上部署 CI/CD。一些最新的 CI/CD 產(chǎn)品在 Kubernetes 集群上的容器中運行，這些集群在本地和云中運行同樣愉快。在混合部署方案中，你可以將每個(gè)組件放置在考慮到開(kāi)發(fā)人員本身的物理位置以及開(kāi)發(fā)基礎結構中其他服務(wù)器的網(wǎng)絡(luò )位置最有意義的位置。

CI/CD 必須與你的存儲庫集成

正如你在閱讀“CI 的端點(diǎn)通常是對軟件存儲庫的主分支的完整簽入”時(shí)可能已經(jīng)收集到的那樣，存儲庫對于 CI 和 CD 至關(guān)重要。

除了作為簽入和測試過(guò)程的終點(diǎn)之外，軟件存儲庫還是存儲 CI 和 CD 腳本和配置文件的首選位置。是的，許多 CI/CD 平臺可以在內部存儲腳本和其他文件，但通常最好將它們置于工具之外的版本控制中。

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

你的 CI/CD 工具需要支持你的編程語(yǔ)言和工具

每個(gè)編程語(yǔ)言或語(yǔ)言組(JVM 語(yǔ)言、LLVM 編譯語(yǔ)言、.NET 語(yǔ)言等)往往都有自己的構建工具和測試工具。為了對你有用，CI/CD 工具必須支持作為給定項目一部分的所有語(yǔ)言。否則，你可能需要為該工具編寫(xiě)一個(gè)或多個(gè)插件。

Docker 鏡像對于分布式、模塊化和微服務(wù)軟件部署變得越來(lái)越重要。如果你的 CI/CD 工具知道如何處理 Docker 鏡像，包括從源代碼、二進(jìn)制文件和先決條件創(chuàng )建鏡像，以及將鏡像部署到特定環(huán)境，那么這將大有幫助。

同樣，如果沒(méi)有這個(gè)，你可能需要編寫(xiě)插件或腳本來(lái)實(shí)現你需要的 Docker 功能。同樣，你希望 CI/CD 工具支持 Kubernetes 和你在環(huán)境中使用的任何其他容器編排系統。

你的開(kāi)發(fā)人員是否了解 CI/CD 和你正在考慮的工具?

CI 和 CD 的原理看似顯而易見(jiàn)，但細節卻并非如此。各種 CI/CD 工具具有不同級別的支持和文檔。有很多關(guān)于 Jenkins 的書(shū)，這并不奇怪，因為它是最古老的書(shū)。

對于其他產(chǎn)品，你可能需要調查文檔和支持論壇以及付費支持選項，作為你在選擇工具時(shí)盡職調查的一部分。

關(guān)于CI的一般背景，請考慮Addison-Wesley的書(shū)《持續集成》(Continuous Integration)，作者是Duvall等人。同樣，對于CD的一般背景，可以參考Humble和Farley的Continuous Delivery。兩本書(shū)出版時(shí)都獲得了Jolt獎。

你可以為不同的項目選擇不同的 CI/CD 工具

雖然本指南是關(guān)于選擇 CI/CD 平臺的，但請不要假設一個(gè)平臺對于你的所有軟件開(kāi)發(fā)項目都是最佳的。大多數商店使用多種編程語(yǔ)言和環(huán)境，并不是每個(gè) CI/CD 平臺都能很好地支持所有這些。

隨意選擇最適合你的每個(gè)項目的 CI/CD 平臺，而不是尋找一個(gè)折衷的平臺。CI 和 CD 的一般原則從一個(gè)平臺轉移到另一個(gè)平臺，即使你為它們編寫(xiě)的腳本可能并不總是可移植的。

雖然每個(gè)新平臺的額外入門(mén)時(shí)間可能會(huì )讓你的 DevOps 團隊花費一些時(shí)間，但這很可能比需要廣泛定制 CI/CD 工具更便宜。

規劃未來(lái)的 CI/CD 遷移

同樣，請不要假設給定的 CI/CD 平臺將永遠滿(mǎn)足你的項目需求。始終對沖你的賭注，例如通過(guò)將腳本存儲在存儲庫中而不是在 CI/CD 工具中。

在適當的情況下首選無(wú)服務(wù)器serverless CI/CD

一般來(lái)說(shuō)，云容器部署比云服務(wù)器實(shí)例部署便宜，無(wú)服務(wù)器云部署比容器部署便宜。 不幸的是，在撰寫(xiě)本文時(shí)，很少有 CI/CD 平臺可以無(wú)服務(wù)器運行。

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

少數可以運行無(wú)服務(wù)器的 CI/CD 平臺之一是無(wú)服務(wù)器 CI/CD，它是無(wú)服務(wù)器框架 Pro 的一部分，是開(kāi)源無(wú)服務(wù)器框架的增強版本。無(wú)服務(wù)器 CI/CD 針對部署無(wú)服務(wù)器應用程序進(jìn)行了優(yōu)化，目前僅在 AWS 上運行。你必須確定它是否足夠支持你的應用程序以供使用。

在提交之前做一個(gè)概念證明

一旦完全實(shí)施 CI/CD，它就會(huì )成為基礎設施的重要組成部分。在你加快速度時(shí)請記住這一點(diǎn)。

在開(kāi)始推出 CI/CD 管道之前執行嚴格的概念驗證非常重要。在開(kāi)始 CD 階段之前，先將 CI 部分放下。在將任何 CI/CD 管道連接到生產(chǎn)實(shí)例之前，請確保練習測試套件和回滾功能，并讓人工參與其中，直到你非常確定自動(dòng)化堅如磐石。

原文鏈接：https://www.infoworld.com/article/3620932/how-to-choose-a-cloud-based-cicd-platform.html