2020 年每個人都應該學習的 DevOps 工具

立即開始使用最好的 DevOps 工具！

DevOps 革命終於席捲了世界，DevOps 工具變得異常流行。 根據服務 谷歌趨勢，對「DevOps 工具」的請求數量不斷增長，並且這種趨勢仍在持續。

DevOps 方法涵蓋整個軟體開發生命週期，因此專業人員可以從各種工具中進行選擇。 但是，如您所知，沒有任何工具可以成為每個人的通用工具。 然而，一些解決方案提供瞭如此廣泛的功能，幾乎可以處理任何任務。

讓我們將 DevOps 工具分為幾類，並將它們與類似工具進行比較：

• 開發和建構工具
• 測試自動化工具
• 組織部署的工具
• 運行時工具
• 協作工具。

成功且周到的實施 DevOps實踐者 包括上面列出的所有五個組的樂器。 分析專案中目前的工具集，以免錯過 CI/CD 管道的重要元素。

開發和建構工具

這是 CI/CD 管道堆疊的基礎。 一切就從這裡開始！ 此類別中最好的工具可以管理多個事件流並輕鬆與其他產品整合。

在開發生命週期的這個階段，有三組工具：

• 版本控制系統（SCM）
• 持續整合（CI）
• 資料管理

GIT 在 2020 年取得了良好的記錄，因此您的 SCM 工具應該對 GIT 具有無縫支援。 對於 CI，先決條件是能夠在隔離的容器環境中執行和運行建置。 在資料管理方面，需要能夠根據應用程式版本更改資料庫模式並維護資料庫。

SCM + CI 工具 #1

優勝者： 亞搏體育appGitLab和GitLab-CI

2020 年 DevOps 週期的最佳工具毫無疑問是 GitLab，並且它肯定會在不久的將來繼續引領創新。

GitLab 的主要功能是提供 Git 儲存庫的舒適管理。 網路介面直覺且易於使用。 GitLab 以免費版本提供您所需的一切，並以 SaaS 和本地部署（使用您自己的資源來託管軟體）的形式提供。

沒有其他 SCM 工具直接在您的儲存庫上使用持續整合 (CI)，GitLab 長期以來一直這樣做。 要使用 GitLab-CI，您必須將 .gitlab-ci.yml 檔案新增至原始碼根目錄，對專案的任何變更都會根據您指定的內容觸發操作。 GitLab 和 GitLab-CI 當之無愧地被公認為持續整合（CI-as-code）領域的領導者。

主要優點

• 可靠性－產品自2013年上市以來； 穩定的; 很好的支援。
• 開源 - GitLab 的免費版本不限制開發團隊所需的核心功能。 付費服務包為不同規模和需求的公司提供了額外的實用功能。
• 根深蒂固的 CI - 市場上沒有其他工具像 GitLab-CI 一樣直接建置到 SCM 中的持續整合。 使用 Docker 可確保無障礙的獨立構建，並且內建報告使調試變得輕鬆。 我們不需要同時對多個工具進行複雜的整合和管理。
• 無限整合 - GitLab 提供您所需的所有 DevOps 工具的輕鬆整合。 這確保了開發和維護團隊在任何環境中都擁有有關其應用程式的單一資訊來源。

競爭對手

曾經參加過戰鬥，但沒有獲勝

此類別中還有其他流行的工具，但它們不如 GitLab。 這就是為什麼：

GitHub上 — 這是一個優秀的 SaaS 版本控制系統，適合小型公司和早期開發階段。 對於需要在自己的網路上保留 IP 位址的大公司來說，GitHub 的唯一解決方案是不支援高可用性系統的 .OVA 虛擬機器。 這使得本地維護變得困難；此外，.OVA只適合中型企業，否則伺服器在更大的負載下很容易崩潰。 缺乏 GitHub Actions（直到最近還沒有本地版本）或 CI 即程式碼意味著您需要選擇一個單獨的 CI 工具，然後管理該整合。 最後，GitHub 比 GitLab 的任何一個版本都貴得多。

詹金斯 ——雖然Jenkins預設被認為是持續整合工具中的標準，但它一直缺乏版本控制能力。 原來你使用的是Jenkins加上某種SCM工具。 當 GitLab 能夠同時做到這兩點時，那就太難了。 平庸的使用者體驗設計不適合現代 Web 應用程序，而且還有很多不足之處。

BitBucket/竹子 — 我必須承認他是個自動失敗者：當 GitLab 完全獨立完成所有事情時，為什麼還要使用兩個工具。 BitBucket Cloud 支援 GitLab-CI / GitHub Action 功能，但沒有一家比新創公司更大的公司可以輕鬆實現它。 本地 BitBucket 伺服器甚至不支援 BitBucket 管道！

#1 資料管理工具

優勝者： Flyway資料庫

在 Web 應用程式開發中，資料庫自動化通常不被重視。 為新版本的應用程式部署資料庫架構變更的想法來得很晚。 架構變更通常會導致新增和重新命名列或表。 如果應用程式版本與架構版本不匹配，應用程式可能會崩潰。 此外，由於存在兩個不同的系統，因此在更新應用程式時管理資料庫變更可能具有挑戰性。 FlyWayDB解決了所有這些問題。

主要優點

• 資料庫版本控制 - Flyway 可讓您建立資料庫版本、追蹤資料庫遷移以及輕鬆傳輸或恢復架構更改，而無需額外的工具。
• 二進位或嵌入式 - 我們可以選擇將 Flyway 作為應用程式的一部分或作為二進位執行檔運行。 Flyway 在啟動時檢查版本相容性並啟動適當的遷移，保持資料庫和應用程式版本同步。 透過執行命令列臨時命令，我們為現有資料庫提供了靈活性，而無需重建整個應用程式。

競爭對手

曾經參加過戰鬥，但沒有獲勝

該領域的工具並不多。 讓我們看看其中的一些：

液體基地 — Liquibase 類似於 FlywayDB。 如果我的團隊中有人在 Liquibase 方面擁有更多經驗，我希望將其設置在 Flyway 之上。

植絨 - 只能適用於容器化應用程式。 要成功運行容器化資料庫，一切都必須完美規劃。 我建議使用 RDS（關聯式資料庫服務）作為資料庫，並且不建議將重要資訊儲存在容器中。

測試自動化工具

讓我們根據測試金字塔對測試自動化工具進行分類來開始討論。

測試金字塔（測試）有 4 個等級：

• 單元測試－這是整個自動化測試過程的基礎。 與其他類型的測試相比，應該有更多的單元測試。 開發人員編寫並執行單元測試，以確保應用程式的一部分（稱為“單元”）符合其設計並按預期運行。
• 元件測試- 元件測試的主要目的是驗證測試物件的輸入/輸出行為。 我們必須確保測試對象的功能按照規格正確實現。
• 整合測試 - 一種將各個軟體模組組合起來並作為一個群組進行測試的測試。
• 端對端測試 - 此步驟是不言自明的。 我們監控整個應用程式並確保其按計劃運行。

由於單元測試和元件測試僅由開發人員執行，並且通常是特定於程式語言的，因此我們不會針對 DevOps 領域評估這些工具。

#1 整合測試工具

優勝者： 黃瓜

Cucumber 將規格和測試文檔合併到一個活動文檔中。 這些規範始終是最新的，因為它們是由 Cucumber 自動測試的。 如果您想從頭開始建立自動化測試框架並在 Web 應用程式中對使用者行為進行建模，那麼帶有 Java 和 Cucumber BDD 的 Selenium WebDriver 是在專案中學習和實作 Cucumber 的好方法。

主要優點

• BDD 方法（行為驅動開發 - 「透過行為進行開發」而不是「測試驅動開發」方法）- Cucumber 是為 BDD 測試而設計的，它最初就是為了這個任務而創建的。
• 動態文檔 - 文件總是很痛！ 由於您的測試是作為程式碼編寫的，Cucumber 會測試自動產生的文檔，以確保測試和文檔同步。
• 支援 - 我們可以從許多工具中進行選擇，但 Cucumber 擁有必要的財務資源和組織良好的支援系統，可以在任何困難情況下幫助使用者。

競爭對手

曾經參加過戰鬥，但沒有獲勝

在其他框架和技術專用工具中，只有 Cucumber 可以被認為是通用解決方案。

端對端測試工具

在進行端到端測試時，需要專注於兩個關鍵點：

• 功能測試
• 壓力測試。

在功能測試中，我們檢查我們想要的一切是否真的發生了。 例如，當我點擊 SPA（單頁應用程式）的某些元素、填寫表格並選擇「提交」時，資料會出現在資料庫中，並且螢幕上會出現訊息「成功！」。

對於我們來說，檢查是否可以正確處理運行相同場景的一定數量的用戶也很重要。

缺乏這兩種類型的測試將是 CI/CD 管道中的一個重大缺陷。

#1 端對端測試工具。 功能測試

優勝者： SoapUI專業版

自從基於 SOAP 的 Web 服務成為標準以來，SoapUI 已經進入 API 測試領域很久了。 雖然我們不再創建新的 SOAP 服務並且該工具的名稱也沒有更改，但這並不意味著它沒有發展。 SoapUI 提供了一個用於建立自動化後端功能測試的優秀框架。 測試可以輕鬆地與持續整合工具結合，並用作 CI/CD 管道的一部分。

主要優點

• 詳細文件 - SoapUI 已經上市很長時間了，因此有許多線上資源可以幫助您了解如何設定測試。
• 易於使用 - 儘管該工具支援用於測試 API 的多種協議，但 SoapUI 為多種服務提供的通用介面使編寫測試變得更加容易。

競爭對手

曾經參加過戰鬥，但沒有獲勝

硒 是該組中的另一個出色的樂器。 如果您正在建立和運行基於 Java 的應用程序，我建議您使用它。 但是，如果您正在使用多種技術建立完整的 Web 應用程序，那麼對於非 Java 元件來說它可能會變得難以使用。

#1 端對端測試工具。 壓力測試

優勝者： 加載程序

說明： 當需要對應用程式的每個元素進行負載測試時，只有 LoadRunner 可以完成任務。 是的，一開始它既昂貴又困難，但 LoadRunner 是唯一能讓我作為技術架構師完全相信新程式碼可以在極端負載條件下工作的工具。 另外，我認為現在是時候讓 LoadRunner 由開發團隊而不是測試團隊接手了。

主要優點

• 豐富的文件 - LoadRunner 已經上市相當長一段時間了，因此有許多線上資源可以幫助您了解如何設定負載測試。
• 協定支援 - Load Runner 支援從 ODBC 到 AJAX、HTTPS 以及您的應用程式可能使用的任何其他重要協定的所有內容。 我們盡量不使用多種工具進行負載測試，因為這只會讓過程變得複雜。

競爭對手

曾經參加過戰鬥，但沒有獲勝

同樣，該領域沒有很多通用工具，因此最好的解決方案是可以在任何環境中使用任何技術的解決方案。

部署工具

部署工具可能是開發中最不被理解的方面。 對於沒有深入了解應用程式的程式碼和功能的營運團隊來說，很難使用此類工具。 對於開發人員來說，部署管理是一項新職責，因此他們還沒有足夠的使用此類工具的經驗。

首先，我們將所有部署工具分為三個子類別：

• 工件管理
• 配置管理
• 部署。

#1 工件管理工具

優勝者： 關係

Nexus 工件儲存庫支援幾乎所有主要技術，從 Java 到 NPM 到 Docker。 我們可以使用這個工具來儲存我們使用的所有工件。 代理遠端套件管理器還可以顯著加快 CI 建置流程，使套件更易於建置。 另一個優點是能夠獲得多個軟體專案中使用的所有軟體包的完整視圖，阻止不安全的開源軟體包（它們可以充當攻擊媒介）。

主要優點

• 技術支援－可靠的產品； 很好的支援。
• 開源 - 免費版本不限制開發團隊所需的核心功能。

#1 設定管理工具

優勝者： Ansible

Ansible 成為領導者的原因很簡單：無狀態。 以前，類似的工具專注於配置狀態管理。 啟動時，此類工具在收到所需的配置後，將嘗試修正目前的應用程式配置。 而採用新方法時，只存在無狀態組件。 新版本的程式碼是部署來取代現有程式碼的工件。 這可以被認為是一種短暫的、短期的環境。

主要優點

• 無狀態 - Playbook 從部署電腦啟動並在目標伺服器上執行。 透過使用像 Packer 這樣的工具來建立可部署對象，我不必擔心遠端對象的狀態。
• 開源 - 與 CentOS 一樣，Ansible 也受 RedHat 支援。 它有助於維護社區並提供高品質、易於使用的模組。
• 使用 Molecule（Ansible 框架）進行測試 - 由於設定管理是程式碼，就像其他一切一樣，測試至關重要。 Molecule 的 Ansible 角色測試框架完美運行，確保配置具有相同的質量，並遵循與應用程式程式碼相同的 CI/CD 管道。
• YAML - 與其他工具相比，YAML 更容易理解。 由於配置管理對於實施 DevOps 實踐的人來說通常是一個新的挑戰，因此簡單性是它的王牌。

競爭對手

曾經參加過戰鬥，但沒有獲勝

操作代碼廚師 — 我作為食譜開發人員開始了我的 DevOps 職業生涯。 Ruby 和 Chef 當然是我非常喜歡的，但它們根本無法解決現代無狀態、雲端原生應用程式的問題。 OpsCode Chef 對於更傳統的應用程式來說是一個很棒的工具，但在本文中我們將專注於未來。

木偶 — Puppet 從來沒有太多粉絲，尤其是與 Chef 和 A​​nsible 相比。 它非常適合配置和使用硬件，但缺乏對 Web 應用程式的現代組態管理支援。

部署工具#1

優勝者： Terraform

Terraform 解決了將基礎設施描述為程式碼的問題，從網路元件到完整的伺服器映像。 自從最初發布以來，該產品已經取得了長足的進步，創建瞭如此多的插件並建立瞭如此強大的社區，您一定會在任何部署場景中獲得幫助。 支援任何類型環境（本地、雲端或其他地方）的能力是無與倫比的。 最後，最新版本在 HCL 中提供了與任何其他傳統程式語言相同的邏輯函數和類，使 Terraform 易於開發人員快速輕鬆地掌握。

主要優點

• 與環境無關 - Terraform 使用充當 Terraform 程式碼、所有 API 和內部邏輯之間介面的函數來與基礎設施提供者進行通訊。 這意味著我只需掌握一種工具，然後就可以在任何地方工作。
• 開源 - 很難打敗免費工具！ 最高層級的社區支持。

競爭對手

曾經參加過戰鬥，但沒有獲勝

AWS 雲形成 — 即使您只在 AWS 雲端環境中工作，您的下一份工作也可能會使用不同的工具。 將所有時間和精力投入到一個平台上是一個短視的決定。 此外，許多新的 AWS 服務通常在 CloudFormation 中提供之前作為 Terraform 模組提供。

運行時工具

任何開發項目的最終目標都是將應用程式投入生產。 在 DevOps 世界中，我們希望充分了解環境中所有可能出現的問題，我們也希望最大限度地減少人工幹預。 選擇正確的運行時工具集對於實現應用程式開發天堂至關重要。

運行時工具的子類別：

• X 即服務 (XaaS)
• 編排
• 監控
• 記錄。

X 工具即服務 #1

優勝者： 亞馬遜網絡服務

亞馬遜一直是雲端技術領域的領導者，但它不止於此：為開發人員提供的各種新服務令人大開眼界。 將任何技術和模板引入 AWS，它將被建置並運行。 該工具的成本相當合理：將其與在您自己的資料中心組裝、管理和維護設備進行比較。 免費版本允許您在花錢之前進行試驗並做出正確的決定。

主要優點

• 普遍性 - 如果您有在 AWS 中建立應用程式的經驗，那麼您可以在任何地方工作。 企業喜歡 AWS，新創公司也欣賞它的低成本。
• 免費版本是 AWS 區別於同類產品的一個真正重要的因素。 在我做出購買決定之前，讓我嘗試一下該服務，看看它是如何運作的，我不想花數千美元在不必要的東西上。 免費版本總是足以讓我測試任何概念。

競爭對手

曾經參加過戰鬥，但沒有獲勝

天藍 「自首次發布以來，Azure 已經取得了長足的進步，這是值得讚揚的。 然而，與眾不同的願望導致了服務的奇怪名稱，這往往使工作變得複雜。 「blob 儲存」是什麼意思？ 雖然 .NET 程式碼在 Microsoft 生態系統中表現較好，但您不太可能只對應用程式的每個元件使用 .NET。

Heroku的 — 由於可靠性和透明度較低，我絕不會在 Heroku 上運行個人項目以外的任何項目，因此公司不應將其用作平台。 Heroku 非常適合在部落格上演示某些內容，但對於實際使用來說 - “不，謝謝！”

#1 編排工具

優勝者： 開班

您可能在應用程式堆疊中使用 Docker 或其他容器。 無伺服器應用程式很棒，但它們可能不適合所有架構。 在沒有編排平台的情況下運行容器根本行不通。 Kubernetes Core (K8s) 在安全性和工具方面無與倫比。 OpenShift 是唯一一個基於 Kubernetes 的平台，可以收集 Source2Image，支援自動部署到 pod，並支援追蹤和監控。 OpenShift 可以在本地端、雲端運行，或同時在本地端和雲端運行。

主要優點

• 內建安全性 - 管理 K8s 安全性可能需要高級程度。 每個細節都必須仔細考慮並考慮在內！ OpenShift 預設內建的安全機制減輕了開發人員的負擔，並為應用程式提供了更安全的平台。
• 一體化解決方案 - 與預設不包含負載平衡工具的基本 K8 不同，OpenShift 擁有這一切。 我可以使用它來建立和託管容器、運行 CI/CD 工具、管理外部進程、管理金鑰等等。 儘管圖形使用者介面還遠未達到完美，但基於 API 的方法意味著一切都可以在腳本中描述。 與其他 K8s GUI 不同，OpenShift 讓學習 Kubernetes 的基礎知識變得更加容易。 您甚至不需要獲得學位！

競爭對手

曾經參加過戰鬥，但沒有獲勝

碼頭工人 — Docker Swarm 試圖透過擺脫許多東西來簡化 K8s。 它對於小型應用程式來說非常有用，但對於企業應用程式來說它不起作用。 此外，AWS ECS 等解決方案採用類似的方法，但可以更輕鬆地與我可以互動的其他服務（Lambda、IAM 等）一起使用。

監控工具#1

優勝者： 新遺物

New Relic 的早期版本做得很好——APM（應用程式效能監控）監控。 現在它是一個功能齊全的監控工具，可讓您監控伺服器、容器、資料庫效能、最終用戶體驗監控，當然還有應用程式效能監控。

主要優點

• 易於使用——當我作為系統工程師時，我使用過很多監控工具，但我從未遇到像 New Relic 這樣簡單易用的工具。 它是 SaaS，因此您無需自己安裝。
• 端對端可見性 - 其他工具嘗試監視應用程式的一個特定元素。 例如，處理器使用率或網路流量的指標，但所有這些都必須全面監控，應用程式才能正常運作。 New Relic 讓您能夠將所有資料整合在一起，以全面了解正在發生的情況。

競爭對手

曾經參加過戰鬥，但沒有獲勝

ZABBIX — 我的第一個也是最喜歡的監控系統，但由於雲端技術和APM應用程式效能監控領域缺乏發展，它一直停留在過去。 Zabbix 仍然可以很好地進行傳統的伺服器基礎設施監控，但僅此而已。

DataDog — 過度關注管理應用程式生產環境的流程，而不是程式碼本身。 有了涉及開發人員的 DevOps 團隊，我們不必依賴難以使用的工具來提供一流的支援。

記錄工具#1

優勝者： Splunk的

很難與 Splunk 競爭！ 長期以來，他仍然是伐木領域的領導者，並且繼續比其他人做得更好。 借助本地部署和 SaaS 產品，您可以在任何地方使用 Splunk。 最大的缺點是它的價格：Splunk 仍然非常昂貴！

主要優點

• 普及 - 企業喜歡 Splunk，而且公司有錢購買它。
• 儘管新創公司正在努力收回成本，但由於開源類似物，許多功能都可以解決。
• 可維護性——簡單地說，Splunk 有效並且做得很好。 它帶有許多可供使用的預設設定和功能。 無需浪費時間閱讀文件並嘗試讓 Splunk 工作或破解任何內容。

競爭對手

曾經參加過戰鬥，但沒有獲勝

ELK 堆疊（ElasticSearch、LogStash 和 Kibana） “這些工具似乎是最受歡迎的，因為你甚至不需要賣掉你的肝臟來使用它們。” 然而，隨著日誌集的增長和船上應用程式數量的增加，工作變得越來越困難。 與 Splunk 相比，使用 ELK Stack，我在創建任何儀表板之前花費了比以前更多的時間來設定工具。

協作工具

DevOps 主要是為了改變組織內的文化。 購買任何工具都不會在一夜之間改變當前的做法，但它肯定可以鼓勵協作和新的互動方式。

協作工具的子類別：

• 任務追蹤
• 聊天操作
• 文檔。

#1 問題追蹤工具

優勝者： 吉拉

儘管該領域的競爭日益激烈，但 Jira 仍然保持領先地位。 Jira 令人難以置信的靈活性使開發和維護團隊能夠管理專案工作和衝刺任務。 使用敏捷術語的內建標準可以更輕鬆地從傳統工作方式轉變為更有效率的流程。

主要優點

• 受歡迎程度 - 與許多其他工具一樣，Jira 幾乎無處不在。 小團隊使用更便宜、更容易訪問的版本並獲得他們需要的一切，而大公司則可以負擔更昂貴的許可證。
• 整合 - Jira 是該領域的先驅。 這一事實以及產品的快速發展導致其他公司選擇 Jira 來創建自己的集成，從而增加了該工具的價值。 我們可以透過一些配置將 Jira 與本文列出的所有工具整合在一起。

競爭對手

曾經參加過戰鬥，但沒有獲勝

Trello — Trello 憑藉其免費的看板工具迅速流行起來。 然而，一旦流程規模擴大並且任務從數十個增加到數千個，Trello 就會變得難以導航、搜尋和報告。

Pivotal Tracker — 當我在一家新創公司工作時，我非常喜歡這個工具。 然而，Pivotal Tracker 更專注於產品管理而不是技術任務。 儘管 Jira 中的產品管理稍微複雜一些，但仍可以在不使用額外工具的情況下實現。

聊天操作工具#1

優勝者： MatterMost

說明： 也許我的選擇帶給您最大的驚喜，這是個好消息！ MatterMost 透過借鑒先前工具的優點並將其部署在本地而受到歡迎。 這對公司來說非常重要：MatterMost 允許您控制數據，還可以幫助您將其與本地運行的工具整合。 我們不再需要走出防火牆來檢查工作聊天記錄。

主要優點

• 開源 – MatterMost 的開源版本非常適合中型和大型團隊。 與 Slack 的免費方案不同，Slack 的免費方案會刪除您的訊息歷史記錄，運行您自己的伺服器意味著您保留所有資料。
• 整合 - 由於 API 幾乎 100% 是基於 Slack API，因此幾乎所有 Slack 整合都可以直接與 MatterMost 一起使用。

競爭對手

曾經參加過戰鬥，但沒有獲勝

鬆弛 — Slack 很酷，但這些人已經發展得如此之快，以至於他們開始尋求利潤。 業務的投資回收階段即將到來，這將帶走它們的主要價值：Slack 免費提供服務； 免費版本最重要的缺點是刪除聊天記錄。

微軟團隊 — 嘗試將 Microsoft 產品與非 Microsoft 擁有的產品整合...祝你好運！ 這就是我要說的關於這個工具的全部內容！

文檔工具#1

優勝者： 合流

無論您使用什麼工具，創建和維護高品質的技術文件都是一個複雜的過程。 儘管最近市場上出現了許多 SaaS 文件工具，但我發現很難將任務關鍵型應用程式的技術文件的儲存外包給第三方。 最好在本地儲存資料和文檔，這就是 Confluence 解決問題的方法。

主要優點

• 易於操作 - 大多數獨立工具的設定和操作可能有點複雜，並且需要一些知識來維護。 Confluence Server 開箱即用，適合 10 或 10,000 位使用者。
• 外掛 - Confluence 擁有漂亮、易於使用的開箱即用導航，並且為幾乎所有內容添加插件的能力釋放了類似 Wiki 的潛力。

競爭對手

曾經參加過戰鬥，但沒有獲勝

閱讀文件 — 對於開源來說很酷，但甚至不要考慮在這裡儲存關鍵知識。

降價促銷 - 非常適合記錄程式碼，但由於 MarkDown 的特定格式，很難發布架構、流程或其他類型的文件。

傑奇 — 在記錄技術知識時，我不想建立一個每次發生變更時都會部署的新靜態網站。 Confluence 簡單的版本控制系統大幅簡化了內部文件。

綜合

市場上確實有數百種 DevOps 工具，因此很難知道該使用哪些工具以及何時實施它們。 請按照這個簡單的指南為完整的 CI/CD 管道選擇 DevOps 工具。

請務必從所有五個類別中選擇工具：

• 開發和建構工具
• 測試自動化工具
• 部署工具
• 運行時工具
• 協作工具。

主要推薦： 自動化一切！

謝謝扎克·夏皮羅！

來源： www.habr.com