建議收藏！2020 年必備的幾個 DevOps 工具

?

• 開發(fā)和構建工具

• 自動化測試工具

• 部署工具

• 運行時 DevOps 工具

• 協(xié)作 DevOps 工具

開發(fā)和構建工具

• 源代碼控制管理（SCM）

• 持續(xù)集成（CI）

• 數(shù)據(jù)管理

2020年排名第一的SCM + CI工具：Gitlab和Gitlab-CI

主要優(yōu)勢：

• 成熟度 - 該產(chǎn)品自2013年以來一直投放市場，并且非常穩(wěn)定并且得到了很好的支持。

• 開源 - Gitlab的免費版沒有削減開發(fā)團隊所需的核心功能。每個付費層都提供了附加功能，這些附加功能可根據(jù)組織的規(guī)模和需求帶來極高的價值。

• 易用的 CI -? 市場上沒有其他工具可以像Gitlab-CI一樣直接將持續(xù)集成直接嵌入到您的SCM中。使用Docker構建進行臨時構建的能力提供了無憂的構建作業(yè)，并且內(nèi)置的報告使調(diào)試構建失敗變得容易。無需復雜的集成和業(yè)務流程就可以對多種工具進行編排。

• 無限集成 - Gitlab提供了每個核心DevOps類別中所需工具的輕松集成。這使開發(fā)人員和操作人員在任何環(huán)境中都可以使用一個真實的來源來獲取與其應用程序相關的信息。

競爭對手:

還有其他工具在此領域也很流行，但是它們不如Gitlab。原因如下：

• GitHub - GitHub 一直是小型和早期開發(fā)商店的出色 SaaS 源代碼管理系統(tǒng)。但是，對于需要在網(wǎng)絡中保留其IP的大型企業(yè)，GitHub 的唯一選擇是.OVA不支持高可用性的虛擬機。這使其難以維護 on-prem，并且只能在中型組織中運行，然后服務器本身才開始崩潰。它缺少 GitHub Actions（直到最近，但仍不在本地版本中）或CI-as-Code，這意味著您始終需要帶上自己的CI工具并管理該集成。最后，它比任何 Gitlab 定價都昂貴。

• Jenkins - 盡管Jenkins已經(jīng)成為持續(xù)集成工具的默認標準，但它始終缺少源代碼控制元素。意味著，您將始終使用Jenkins 和 SCM工具。當像 GitLab 這樣的工具同時提供這兩種功能時，這簡直是不必要的復雜。它可怕的UX使得現(xiàn)代Web應用程序有很多不足之處。

• BitBucket/Bamboo - 我不得不說，這是一個自動失敗者，考慮到您需要兩種工具來完成 Gitlab 的一項工作。盡管 BitBucket 云支持 Gitlab-CI / GitHub Action功能，但沒有一家公司（規(guī)模超過一家初創(chuàng)公司）可以輕易采用它。用于本地的 BitBucket 服務器甚至不支持 BitBucket 管道！

2020年排名第一的數(shù)據(jù)管理工具：FlywayDB

競爭對手：

• LiquiBase -? Liquibase 是相似的，實際上，如果有人在我的組織中工作過，那么我很樂意通過 FlyWay 對該工具進行標準化。
• Flocker - 這可能僅適用于容器化的應用程序-在容器中運行數(shù)據(jù)庫非常困難，必須精心計劃才能成功執(zhí)行。我建議將 RDS 之類的服務用于數(shù)據(jù)庫，而不要嘗試運行存儲在容器中的關鍵數(shù)據(jù)。

自動化測試工具

• 單元測試 - 這是所有自動化測試的基礎。就數(shù)量而言，與其他類型相比，您應該擁有最多的單元測試。這些測試應由軟件開發(fā)人員編寫和運行，以確保應用程序的一部分（稱為“單元”）符合其設計并按預期運行。
• 組件測試 -? 組件測試的主要目的是驗證測試對象的輸入/輸出行為。這樣可以確保測試對象的功能按照所需規(guī)范正確運行。
• 集成測試 -??這是測試階段，在此階段中，各個軟件模塊被組合在一起并作為一個整體進行測試。
• 端到端測試 - 此層是不言自明的。我們正在研究從頭到尾的應用程序流程，并使其表現(xiàn)出預期的效果。

2020年排名第一的集成測試工具：Cucumber

Cucumber 將規(guī)范和測試文檔合并為一個有凝聚力的有效文檔。由于它們是由 Cucumber 自動測試的，因此您的規(guī)格始終是最新的。如果您想開始構建 Web 自動化測試框架并在 Web 應用程序上模擬用戶行為，那么帶有 Java 和 Cucumber BDD 的 Selenium WebDriver 是在項目中學習和實現(xiàn) Cucumber 的好方法。

主要優(yōu)勢：

• 行為驅(qū)動的開發(fā) — Cucumber用于BDD測試，它已成為一種入門測試框架（與傳統(tǒng)的測試驅(qū)動開發(fā)相比）。
• 動態(tài)文檔 - 記錄您所做的事情總是很痛苦。由于您的測試被定義為代碼，因此Cucumber測試會自動生成文檔以進行匹配以確保它們始終保持同步。
• 支持 - 這里有很多工具可供選擇，但是當情況變得嚴重時，您需要工具維護者的認真支持。黃瓜擁有足夠的資金和支持結構來維持該工具的未來幾年。

競爭對手：

在這個領域中有許多框架和特定于技術的工具，但是只有 Cucumber 接近于“一刀切”的解決方案。

端到端測試工具

• 功能測試
• 負載測試

2020年排名第一的端到端測試工具 — 功能：SoapUI Pro

• 廣泛的文檔 - 此工具已經(jīng)存在了一段時間，因此有許多在線資源可幫助您確定如何配置負載測試。
• 易于使用 — 盡管有多種API測試工具可用，但擁有一個用于多種服務的接口可以使構建測試變得簡單。

• Selenium - Selenium是該領域的另一個出色工具。如果您正在構建和運行基于Java的應用程序，則建議使用它。但是，如果您要使用多種技術來處理一個完整的Web應用程序，那么對于非Java語言的用戶來說可能會有些笨拙。

2020年排名第一的端到端測試工具 — 負載測試：LoadRunner

• 廣泛的文檔 - 該工具已經(jīng)存在了一段時間，因此有許多在線資源可以幫助您確定如何配置負載測試。
• 協(xié)議支持 - 從ODBC到AJAX，再到HTTPS以及您的應用程序可能在某處使用的其他晦澀協(xié)議，LoadRunner支持該協(xié)議。我們要避免串接多個負載測試工具-這只會增加復雜性。

部署工具

• 構件管理
• 配置管理
• 部署方式

2020年排名第一的制品管理工具：Nexus

• 技術支持 - 該產(chǎn)品自2013年以來一直投放市場，并且非常穩(wěn)定且得到了很好的支持。
• 開源 - Gitlab的免費版本沒有削減開發(fā)團隊需要的核心功能。每個付費層均提供附加功能，這些附加功能可帶來最大價值，具體取決于組織的規(guī)模和需求。

2020年排名第一的配置管理工具：Ansible

• 無狀態(tài) - Ansible劇本是從操作員機器上運行的，并命中服務器目標。我不在乎遠程對象的狀態(tài)，這使得使用Packer之類的工具來構建可部署對象變得更加容易。
• 開源 - 和CentOS一樣，Ansible也由RedHat維護。該企業(yè)及其高級支持人員可以幫助維護社區(qū)，并確保高質(zhì)量，易于使用的模塊。
• 分子測試 — 因為配置管理和其他任何東西一樣都是代碼，所以如果不對其進行測試，我們將無所不能。用于測試Ansible角色的分子框架可以無縫地工作，以確保我們的按代碼配置質(zhì)量一樣高，并遵循與應用程序代碼相同的CI / CD管道。
• YAML — 與其他工具相比，YAML更加容易使您頭腦清醒。由于配置管理對于采用DevOps的任何人來說通常都是新事物，因此這使其成為關鍵賣點。

• OpsCode Chef - 我以廚師食譜開發(fā)人員的身份開始了DevOps生涯。露比和廚師很親密，我的心。但是，它們根本無法解決當今無狀態(tài)，云原生應用程序的問題。對于更傳統(tǒng)的遺留應用程序來說，這是一個很好的工具，但是本文將重點放在未來。
• Puppet — Puppet從未成長為一個龐大的社區(qū)，特別是與Chef and Ansible相比。它非常適合配置和裸機，但不支持Web應用程序類型的配置管理。

2020年排名第一的部署工具：Terraform

Terraform解決了從網(wǎng)絡組件到實際服務器映像定義基礎架構即代碼的問題。自最初發(fā)布以來，它已經(jīng)走了很長一段路，并建立了龐大的插件社區(qū)和支持社區(qū)，以幫助您解決可能遇到的幾乎所有部署場景。支持本地，云中或其他任何類型的環(huán)境的能力是首屈一指的。最后，最新版本在HCL中提供了許多與其他任何傳統(tǒng)編程語言相同的邏輯功能和類，從而使開發(fā)人員可以輕松學習和學習。

主要優(yōu)勢：

不受云/環(huán)境影響 - Terraform利用提供的資源作為Terraform代碼與與基礎架構提供商進行通信所需的所有API和后端邏輯之間的接口。這意味著我可以學習一種工具，并且能夠在任何地方工作。

開源 — 同樣，很難敲響免費工具。社區(qū)支持是一流的。

競爭對手：

AWS CloudFormation — 即使您僅在AWS云環(huán)境中工作，您也可能會在職業(yè)生涯中繼續(xù)前進，而不是去那里。將您的技能和知識整合到一個平臺中可能會有風險。此外，許多新的AWS服務通常在CloudFormation中可用之前作為Terraform模塊提供。

運行時 DevOps 工具

• X 即服務
• 編排
• 監(jiān)控方式
• 日志記錄

2020年排名第一的編排工具：OpenShift

您可能在應用程序堆棧中的某處使用了Docker或容器。無服務器應用程序很棒，但它們不能適合所有的架構模式。在沒有業(yè)務流程平臺的情況下運行容器根本行不通。從安全性和工具角度來看，Core Kubernetes帶來了很多需求。OpenShift是唯一擁有Kubernetes平臺的平臺，它具有Source2Image構建，pod中的部署自動化以及甚至可追溯性和監(jiān)視功能。它可以在本地，云中或同時在兩者中運行。

主要優(yōu)勢：

• 內(nèi)置的安全性 - 管理K8安全性幾乎需要博士學位。必須仔細考慮并考慮所有細節(jié)。默認情況下，OpenShift所采用的安全機制減少了開發(fā)人員的工作量，并為他們的應用程序提供了更安全的平臺。

• 多合一解決方案 – 與默認不包含負載平衡工具的香草K8不同，OpenShift擁有一切。我可以使用它來托管我的容器，構建容器，運行CI / CD工具，協(xié)調(diào)外部流程，管理機密等等。盡管GUI仍然需要做更多的工作，但API優(yōu)先的方法意味著一切都可以編寫腳本，并且與K8的其他GUI不同，它使學習Kubernetes的基礎知識變得更加簡單，而無需首先獲得該學位！

競爭對手：

Docker Swarm - Docker swarm嘗試通過刪除大量內(nèi)容來簡化K8。這對于較小的應用程序非常有用，但對于企業(yè)應用程序則根本不起作用。此外，AWS ECS之類的服務采用了類似的方法，但是使我可能正在與之交互的其他服務（Lambda，IAM等）的使用變得更容易。

2020年排名第一的監(jiān)控工具：New Relic

New Relic的早期發(fā)行版確實做得非常好-APM監(jiān)視。現(xiàn)在，它是一套完整的監(jiān)視工具，使我可以監(jiān)視服務器性能，容器性能，數(shù)據(jù)庫性能，最終用戶體驗監(jiān)視，當然還有APM監(jiān)視。

• 易用性 - 我在擔任系統(tǒng)工程師時曾使用過許多監(jiān)視工具，但從未遇到過像New Relic這樣易于使用的監(jiān)視工具。這是一個SaaS，因此不必設置服務器組件也很不錯。
• 端到端可見性 - 其他工具嘗試監(jiān)視應用程序的一個特定方面。無論是CPU利用率還是網(wǎng)絡流量，所有這些層都可以協(xié)同工作，以使您的應用正常運行。New Relic使您能夠組合所有數(shù)據(jù)以真實了解正在發(fā)生的事情。

• Zabbix — Zabbix是我最喜歡的監(jiān)視系統(tǒng)，但是由于缺乏向云原生環(huán)境和APM空間發(fā)展的能力，因此使其滯后。它仍然可以很好地監(jiān)視傳統(tǒng)的服務器基礎結構，僅此而已。
• DataDog - 此工具過于側(cè)重于管理生產(chǎn)應用程序的過程視角，而對代碼本身的關注不足。在真正的DevOps團隊中，有開發(fā)人員參與生產(chǎn)，我們無需依靠繁瑣的工具來提供世界一流的支持。

協(xié)作 DevOps 工具

DevOps首先是組織內(nèi)部的文化變革。雖然購買工具不會一夜之間改變文化，但無疑可以幫助培養(yǎng)與同事合作的新方法。

協(xié)作工具子類別為：

• 問題跟蹤

• 聊天操作

• 文獻資料

2020年排名第一的問題跟蹤工具：Jira

• 行業(yè)標準 — 同樣，就像許多工具一樣，Jira到處都有使用。小型團隊可以使用便宜的許可證并獲得所需的一切，而企業(yè)可以為任何人負擔得起許可證。
• 集成 - 在這個領域處于領先地位并且快速增長意味著第三方工具會選擇您首先構建本機集成，而它們只會增加您工具的價值，而Jira就是這種情況。我們可以與現(xiàn)成的列表中的所有其他工具集成，而無需進行任何定制。

• Trello — Trello成為免費使用的看板工具，因此迅速流行。但是，一旦事情開始擴展，并且您從數(shù)十個問題擴展到數(shù)千個問題，Trello將變得難以導航，搜索和報告。
• Pivotal Tracker - 在初創(chuàng)公司工作期間，我非常喜歡該工具。但是，他們更多地關注產(chǎn)品管理，而不是技術任務。盡管從Jira進行產(chǎn)品管理比較困難，但是仍然可以完成此過程，而不必獲取完全獨立的工具。

2020年排名第一的ChatOps工具：MatterMost

說明：這可能是2020年這份清單上最大的驚喜，這是一件好事！MatterMost通過使用以前最好的工具，但引入了本地部署而獲得了普及。對于企業(yè)來說，這是巨大的，因為它可以控制數(shù)據(jù)，還可以幫助與本地工具集成-我們不再需要為了新的事物而走出防火墻。

主要優(yōu)勢:

開源 - MatterMost的開源版本非常適合小型或大型團隊。與Slack的免費層會丟失歷史記錄不同，您自己運行服務器意味著您擁有數(shù)據(jù)。
集成 - 因為API幾乎100％基于Slack API，所以幾乎所有Slacks集成都可以直接與MatterMost一起使用。

競爭對手:

• Slack - 松弛很棒，但是它們已經(jīng)變得如此龐大，需要開始獲利。他們業(yè)務的付費階段即將到來，并且剝奪了Slack用來免費提供的許多價值，最關鍵的是聊天記錄。

• Microsoft Teams - 嘗試將Microsoft產(chǎn)品與非Microsoft本地產(chǎn)品集成-祝您好運。這就是我要說的！

2020年排名第一的文檔工具：Confluence

無論使用哪種工具，都很難創(chuàng)建和維護高質(zhì)量的技術文檔。盡管最近有許多SaaS文檔工具進入市場，但我很難接受將有關關鍵應用程序的敏感技術文檔存儲給第三方。我需要將數(shù)據(jù)和文檔保留在本地，這就是Confluence為我所做的。

主要優(yōu)勢：

易于管理 - 大多數(shù)自托管工具的啟動和運行可能有些復雜，并且大規(guī)模維護它們需要一些特定知識。開箱即用的Confluence服務器非常適合10個用戶或10,000個用戶。
插件－ 盡管創(chuàng)建具有默認融合功能的漂亮且易于瀏覽的文檔已經(jīng)很不錯了，但是擁有用于幾乎所有內(nèi)容的插件的能力釋放了Wiki的潛力。

競爭對手：

• Read the docs — 非常適合開源公共代碼，但永遠不會考慮在這里存儲關鍵的應用程序知識。

• MarkDown — 盡管非常適合于記錄有關我的代碼的內(nèi)容，但很難將體系結構，過程或其他類型的文檔直接放入MarkDown格式中。

• Jekyll — 在記錄技術知識時，我并不想簡單地構建一個新的靜態(tài)站點，以便在每次更改時進行部署。簡單的Confluence版本管理系統(tǒng)使內(nèi)部文檔的處理變得更加容易。

總結 2020 年最佳

市場上實際上有數(shù)百種DevOps工具。試圖瀏覽應使用哪些以及何時實施它們可能會令人不知所措。遵循此簡單指南，為完整的CI / CD管道選擇DevOps工具堆棧。

將工具分為以下五個關鍵領域：

• 開發(fā)和構建工具

• 自動化測試工具

• 部署工具

• 運行時工具

• 協(xié)作工具