提到 DevOps 這個詞，我相信很多人一定不會陌生。作為一個熱門的概念，DevOps近 年來頻頻出現在各大技術社群和媒體的文章中。到了 2020 年，DevOps 的革命也終於成為了一個主流，DevOps 相關工具的受歡迎程度也在激增。根據 Google 趨勢，「DevOps 工具」的搜尋量一直在穩定增長，並且這種趨勢還在持續。
DevOps 工具越來越多，瞭解它們以及知道在什麼時候使用他們越來越重要。由於 DevOps 涵蓋了整個軟體開發生命週期，因此有很多工具可供選擇。讓我們將其大致分為以下幾類：
- 開發和構建工具
- 自動化測試工具
- 部署工具
- 執行時 DevOps 工具
- 協作 DevOps 工具
成功且成熟地採用 DevOps 做法將始終擁有完整的渠道，其中包括適用於這五個類別的工具。確保評估您當前的工具堆疊，以確保您沒有丟失 CI/CD 管道的關鍵部分。
開發和構建工具
這是 CI/CD 管道堆疊的基礎。一切都從這裡開始。該類別中最好的工具可以協調多個事件流，並可以輕鬆地與外部工具整合。
軟體開發生命週期的這一部分中的工具分為三個子類別：
- 原始碼控制管理（SCM）
- 持續整合（CI）
- 資料管理
2020年，推薦的SCM技術是GIT，因此我們的SCM工具必須具有出色的GIT支援。對於CI，絕對需要在臨時容器化環境中執行和執行構建的能力。對於資料管理，我們需要能夠對資料庫架構進行更改並使它與應用程式版本保持一致。
2020年排名第一的SCM + CI工具：Gitlab和Gitlab-CI
Gitlab無疑是2020年最偉大的DevOps Lifecycle工具，它將在可預見的未來成為創新的領導者。
Gitlab的核心功能提供了一個完美的GIT儲存庫管理工具。它基於Web的使用者介面是最冗長且易於使用的。Gitlab的免費套餐可提供您所需的一切，並且具有SaaS和On-Prem尺寸。
市場上有很多SCM工具，但是沒有一種工具像Gitlab多年來所做的那樣將“持續整合”直接整合到您的儲存庫中。稱為Gitlab-CI，將.gitlab-ci.yml檔案貼上到程式碼庫的根目錄中，任何GIT事件都會根據您在此處定義的內容觸發操作。他們確實是按程式碼進行持續整合的領導者。
主要優勢：
- 成熟度 - 該產品自2013年以來一直投放市場，並且非常穩定並且得到了很好的支援。
- 開源 - Gitlab的免費版沒有削減開發團隊所需的核心功能。每個付費層都提供了附加功能，這些附加功能可根據組織的規模和需求帶來極高的價值。
- 易用的 CI — 市場上沒有其他工具可以像Gitlab-CI一樣直接將持續整合直接嵌入到您的SCM中。使用Docker構建進行臨時構建的能力提供了無憂的構建作業，並且內建的報告使除錯構建失敗變得容易。無需複雜的整合和業務流程就可以對多種工具進行編排。
- 無限整合 - Gitlab提供了每個核心DevOps類別中所需工具的輕鬆整合。這使開發人員和操作人員在任何環境中都可以使用一個真實的來源來獲取與其應用程式相關的資訊。
競爭對手:
還有其他工具在此領域也很流行，但是它們不如Gitlab。原因如下：
- GitHub - GitHub一直是小型和早期開發商店的出色SaaS原始碼管理系統。但是，對於需要在網路中保留其IP的大型企業，GitHub的唯一選擇是.OVA不支援高可用性的虛擬機器。這使其難以維護on-prem，並且只能在中型組織中執行，然後伺服器本身才開始崩潰。它缺少GitHub Actions（直到最近，但仍不在本地版本中）或CI-as-Code，這意味著您始終需要帶上自己的CI工具並管理該整合。最後，它比任何Gitlab定價都昂貴。
- Jenkins — 儘管Jenkins已經成為持續整合工具的預設標準，但它始終缺少原始碼控制元素。意味著，您將始終使用Jenkins 和 SCM工具。當像GitLab這樣的工具同時提供這兩種功能時，這簡直是不必要的複雜。它可怕的UX使得現代Web應用程式有很多不足之處。
- BitBucket/Bamboo — 我不得不說，這是一個自動失敗者，考慮到您需要兩種工具來完成Gitlab的一項工作。儘管BitBucket雲支援Gitlab-CI / GitHub Action功能，但沒有一家公司（規模超過一家初創公司）可以輕易採用它。用於本地的 BitBucket伺服器甚至不支援BitBucket管道！
2020年排名第一的資料管理工具：FlywayDB
Web應用程式開發中最容易被忽視的方面是資料庫的自動化需求。在應用程式的新版本中部署資料庫架構更改通常是事後的想法。模式更改通常會新增或重新命名列或表。如果應用程式版本與架構版本不匹配，則該應用程式可能會完全損壞。由於存在兩個不同的系統，因此通過應用程式升級來協調資料庫更改也可能很困難。FlyWayDB解決了所有這些問題。
主要優勢：
- 資料庫版本控制 - FlyWay允許您簡單地建立資料庫版本，跟蹤資料庫遷移以及輕鬆地前滾或後退架構更改，而無需某些定製解決方案。
- 二進位制或內建 - 您可以選擇在應用程式啟動時或作為二進位制可執行檔案執行Flyway。在程式碼中使用此工具，以便它在啟動時檢查版本功能並執行適當的遷移，從而使資料庫和應用程式版本保持同步。您也可以臨時執行cmd行，從而在不重建整個應用程式的情況下為現有資料庫提供了靈活性。
競爭對手：
這個空間中沒有太多工具。但是，讓我們來看幾個：
- LiquiBase — Liquibase是相似的，實際上，如果有人在我的組織中工作過，那麼我很樂意通過FlyWay對該工具進行標準化。
- Flocker - 這可能僅適用於容器化的應用程式-在容器中執行資料庫非常困難，必須精心計劃才能成功執行。我建議將RDS之類的服務用於資料庫，而不要嘗試執行儲存在容器中的關鍵資料。
自動化測試工具
我們必須首先將自動化工具安裝到測試金字塔中，從而開始對自動測試工具進行評估。測試金字塔有4層：
- 單元測試 - 這是所有自動化測試的基礎。就數量而言，與其他型別相比，您應該擁有最多的單元測試。這些測試應由軟體開發人員編寫和執行，以確保應用程式的一部分（稱為“單元”）符合其設計並按預期執行。
- 元件測試 — 元件測試的主要目的是驗證測試物件的輸入/輸出行為。這樣可以確保測試物件的功能按照所需規範正確執行。
- 整合測試 — 這是測試階段，在此階段中，各個軟體模組被組合在一起並作為一個整體進行測試。
- 端到端測試 - 此層是不言自明的。我們正在研究從頭到尾的應用程式流程，並使其表現出預期的效果。
由於單元和元件層測試僅由應用程式開發人員驅動，並且通常是特定於程式語言的，因此我們不會在DevOps空間中評估這些工具。
2020年排名第一的整合測試工具：Cucumber
Cucumber將規範和測試文件合併為一個有凝聚力的有效文件。由於它們是由Cucumber自動測試的，因此您的規格始終是最新的。如果您想開始構建Web自動化測試框架並在Web應用程式上模擬使用者行為，那麼帶有Java和Cucumber BDD的Selenium WebDriver是在專案中學習和實現Cucumber的好方法。
主要優勢：
- 行為驅動的開發 — Cucumber用於BDD測試，它已成為一種入門測試框架（與傳統的測試驅動開發相比）。
- 動態文件 - 記錄您所做的事情總是很痛苦。由於您的測試被定義為程式碼，因此Cucumber測試會自動生成文件以進行匹配以確保它們始終保持同步。
- 支援 - 這裡有很多工具可供選擇，但是當情況變得嚴重時，您需要工具維護者的認真支援。黃瓜擁有足夠的資金和支援結構來維持該工具的未來幾年。
競爭對手：
在這個領域中有許多框架和特定於技術的工具，但是隻有Cucumber接近於“一刀切”的解決方案。
端到端測試工具
進行端到端測試時，有兩個重點領域需要關注：
- 功能測試
- 負載測試
功能測試顯然是在測試我們想要發生的事情是否實際發生。當我單擊SPA上的某些頁面，填寫表格並單擊Submit時，資料將顯示在資料庫中，並且螢幕顯示成功！
我們還需要能夠測試在相同場景下工作的x數量的使用者是否可以正確處理。
如果您在這兩個方面都沒有進行測試，則CI / CD管道中的差距將很大。
2020年排名第一的端到端測試工具 — 功能：SoapUI Pro
由於SOAP Web服務是預設的，因此SoapUI進入API測試領域已有很長時間了。儘管我們不再構建新的SOAP服務，並且該工具的名稱沒有更改，但這並不意味著它沒有發展。SoapUI為構建後端Web服務的自動化功能測試提供了一種出色的結構。這些可以輕鬆地與持續整合工具整合，並且可以作為我們的CI / CD管道的一部分執行。
主要優勢：
- 廣泛的文件 - 此工具已經存在了一段時間，因此有許多線上資源可幫助您確定如何配置負載測試。
- 易於使用 — 儘管有多種API測試工具可用，但擁有一個用於多種服務的介面可以使構建測試變得簡單。
競爭對手：
- Selenium - Selenium是該領域的另一個出色工具。如果您正在構建和執行基於Java的應用程式，則建議使用它。但是，如果您要使用多種技術來處理一個完整的Web應用程式，那麼對於非Java語言的使用者來說可能會有些笨拙。
2020年排名第一的端到端測試工具 — 負載測試：LoadRunner
說明：在對應用程式的各個方面進行負載測試時，只有LoadRunner才能完成。是的，這很昂貴而且入門有點困難，但是它是唯一可以執行測試的工具，可以使我作為技術架構師相信新程式碼將在極端壓力下執行。另外，我認為現在是時候讓負載執行技巧從SQA資源轉移到開發團隊了。
主要優勢：
- 廣泛的文件 - 該工具已經存在了一段時間，因此有許多線上資源可以幫助您確定如何配置負載測試。
- 協議支援 - 從ODBC到AJAX，再到HTTPS以及您的應用程式可能在某處使用的其他晦澀協議，LoadRunner支援該協議。我們要避免串接多個負載測試工具-這隻會增加複雜性。
擊敗競爭對手：
再說一次，在這個領域中沒有太多的“一刀切”的工具，因此簡單的解決方案是可以在任何環境中使用任何技術將其丟棄。
部署工具
部署工具可能是應用程式開發中鮮為人知的方面。對於操作人員來說，如果不深入瞭解應用程式程式碼和功能，就很難使用部署工具。對於開發人員來說，管理程式碼部署是一項新的職責，因此他們對許多部署工具的經驗很少。
首先，讓我們將部署工具分為三個子類別：
- 構件管理
- 配置管理
- 部署方式
2020年排名第一的工件管理工具：Nexus
Nexus工件儲存庫支援幾乎所有主要技術，從Java到NPM再到Docker。我們可以使用這一工具來儲存我們所有可部署的工件。通過使軟體包更接近構建過程，代理遠端軟體包管理器的能力還大大提高了我們CI配置的速度。這樣做的另一個好處是，我們可以全域性檢視跨多個軟體專案使用的所有軟體包，從而鎖定不安全的開源軟體包，這些軟體包可能是我們程式碼中的攻擊媒介。
主要優勢：
- 技術支援 - 該產品自2013年以來一直投放市場，並且非常穩定且得到了很好的支援。
- 開源 - Gitlab的免費版本沒有削減開發團隊需要的核心功能。每個付費層均提供附加功能，這些附加功能可帶來最大價值，具體取決於組織的規模和需求。
2020年排名第一的配置管理工具：Ansible
Ansible是這個領域的領導者，原因很簡單：無國籍。較早的現場配置管理工具著重於管理配置狀態。如果它與所需的配置脫離同步，它將自行修復。在新的應用程式中，我們只有無狀態元件。新版本的程式碼是新的構件，並已部署以替換現有的構件。我們擁有短暫的短暫環境。
主要優勢：
- 無狀態 - Ansible劇本是從操作員機器上執行的，並命中伺服器目標。我不在乎遠端物件的狀態，這使得使用Packer之類的工具來構建可部署物件變得更加容易。
- 開源 - 和CentOS一樣，Ansible也由RedHat維護。該企業及其高階支援人員可以幫助維護社群，並確保高質量，易於使用的模組。
- 分子測試 — 因為配置管理和其他任何東西一樣都是程式碼，所以如果不對其進行測試，我們將無所不能。用於測試Ansible角色的分子框架可以無縫地工作，以確保我們的按程式碼配置質量一樣高，並遵循與應用程式程式碼相同的CI / CD管道。
- YAML — 與其他工具相比，YAML更加容易使您頭腦清醒。由於配置管理對於採用DevOps的任何人來說通常都是新事物，因此這使其成為關鍵賣點。
競爭對手：
- OpsCode Chef - 我以廚師食譜開發人員的身份開始了DevOps生涯。露比和廚師很親密，我的心。但是，它們根本無法解決當今無狀態，雲原生應用程式的問題。對於更傳統的遺留應用程式來說，這是一個很好的工具，但是本文將重點放在未來。
- Puppet — Puppet從未成長為一個龐大的社群，特別是與Chef and Ansible相比。它非常適合配置和裸機，但不支援Web應用程式型別的配置管理。
2020年排名第一的部署工具：Terraform
Terraform解決了從網路元件到實際伺服器映像定義基礎架構即程式碼的問題。自最初發布以來，它已經走了很長一段路，並建立了龐大的外掛社群和支援社群，以幫助您解決可能遇到的幾乎所有部署場景。支援本地，雲中或其他任何型別的環境的能力是首屈一指的。最後，最新版本在HCL中提供了許多與其他任何傳統程式語言相同的邏輯功能和類，從而使開發人員可以輕鬆學習和學習。
主要優勢：
不受雲/環境影響 - Terraform利用提供的資源作為Terraform程式碼與與基礎架構提供商進行通訊所需的所有API和後端邏輯之間的介面。這意味著我可以學習一種工具，並且能夠在任何地方工作。
- 開源 — 同樣，很難敲響免費工具。社群支援是一流的。
競爭對手：
- AWS CloudFormation — 即使您僅在AWS雲環境中工作，您也可能會在職業生涯中繼續前進，而不是去那裡。將您的技能和知識整合到一個平臺中可能會有風險。此外，許多新的AWS服務通常在CloudFormation中可用之前作為Terraform模組提供。
執行時DevOps工具
任何開發專案的最終目標都是在生產中執行我們的應用程式。在DevOps世界中，我們希望確保我們對環境中的任何潛在問題具有可見性，並且還希望將人工干預降至最低。選擇正確的執行時工具集對於實現開發必不可少的條件至關重要。
執行時工具子類別為：
- X 即服務
- 編排
- 監控方式
- 日誌記錄
2020年排名第一的X-as-a-Service工具：Amazon Web Services
亞馬遜一直是雲端計算領域的領導者。他們也不僅止步於此-他們為開發人員提供了許多新服務，以利用它可以使您旋轉。將任何技術和任何模式帶到AWS上，就可以構建和執行它。與在自己的資料中心中構建，管理和維護傳統硬體相比，它們的成本極其合理。免費服務層使任何人都有機會在必須做出購買決定之前進行嘗試，這對於嘗試以正確的方式構建應用程式而不必因成本而造成損害非常有用。
主要好處：
- 行業標準 - 如果您有在AWS中構建應用程式的經驗，那麼您基本上可以在任何地方找到工作。企業喜歡AWS，而創業公司喜歡AWS的低成本。
- Free-Tier — 與其他所有功能相比，AWS的業務確實如此。讓我使用該服務並檢視其工作原理，然後再決定將數千美元投入可能有巨大陷阱的事物中。我從未為POC構建的任何產品都超過免費套餐限制。
競爭對手：
- Azure – 自最初發布以來，Azure已經走了很長一段路，值得稱讚。但是，區分自身的需求已導致其對服務的名稱進行了怪異的命名，而這些服務要難一點了-到底什麼是“ blob儲存”？儘管.NET程式碼在Microsoft生態系統中效果更好，但不太可能僅將.NET用於應用程式的各個方面。
- Heroku — 簡而言之，除了在Heroku上的個人專案外，我什麼都不會執行。透明度不高，企業沒有理由將其用作平臺。這對於在部落格中演示某些內容非常有用，但對於實際應用程式來說，非常感謝！
2020年排名第一的編排工具：OpenShift
您可能在應用程式堆疊中的某處使用了Docker或容器。無伺服器應用程式很棒，但它們不能適合所有的架構模式。在沒有業務流程平臺的情況下執行容器根本行不通。從安全性和工具角度來看，Core Kubernetes帶來了很多需求。OpenShift是唯一擁有Kubernetes平臺的平臺，它具有Source2Image構建，pod中的部署自動化以及甚至可追溯性和監視功能。它可以在本地，雲中或同時在兩者中執行。
主要優勢：
- 內建的安全性 - 管理K8安全性幾乎需要博士學位。必須仔細考慮並考慮所有細節。預設情況下，OpenShift所採用的安全機制減少了開發人員的工作量，併為他們的應用程式提供了更安全的平臺。
- 多合一解決方案 – 與預設不包含負載平衡工具的香草K8不同，OpenShift擁有一切。我可以使用它來託管我的容器，構建容器，執行CI / CD工具，協調外部流程，管理機密等等。儘管GUI仍然需要做更多的工作，但API優先的方法意味著一切都可以編寫指令碼，並且與K8的其他GUI不同，它使學習Kubernetes的基礎知識變得更加簡單，而無需首先獲得該學位！
競爭對手：
- Docker Swarm - Docker swarm嘗試通過刪除大量內容來簡化K8。這對於較小的應用程式非常有用，但對於企業應用程式則根本不起作用。此外，AWS ECS之類的服務採用了類似的方法，但是使我可能正在與之互動的其他服務（Lambda，IAM等）的使用變得更容易。
2020年排名第一的監控工具：New Relic
New Relic的早期發行版確實做得非常好-APM監視。現在，它是一套完整的監視工具，使我可以監視伺服器效能，容器效能，資料庫效能，終端使用者體驗監視，當然還有APM監視。
主要優勢：
- 易用性 - 我在擔任系統工程師時曾使用過許多監視工具，但從未遇到過像New Relic這樣易於使用的監視工具。這是一個SaaS，因此不必設定伺服器元件也很不錯。
- 端到端可見性 - 其他工具嘗試監視應用程式的一個特定方面。無論是CPU利用率還是網路流量，所有這些層都可以協同工作，以使您的應用正常執行。New Relic使您能夠組合所有資料以真實瞭解正在發生的事情。
競爭對手：
- Zabbix — Zabbix是我最喜歡的監視系統，但是由於缺乏向雲原生環境和APM空間發展的能力，因此使其滯後。它仍然可以很好地監視傳統的伺服器基礎結構，僅此而已。
- DataDog - 此工具過於側重於管理生產應用程式的過程視角，而對程式碼本身的關注不足。在真正的DevOps團隊中，有開發人員參與生產，我們無需依靠繁瑣的工具來提供世界一流的支援。
2020年排名第一的測井工具：Splunk
很難反對Splunk。他們很久以來一直是日誌聚合的領導者，並且他們繼續做得最好。藉助本地和SaaS產品，您可以在任何地方使用它。主要的缺點是，它仍然很難執行！
主要優勢：
- 行業標準 —企業喜歡Splunk，他們也有錢為此付出代價。雖然初創企業可能難以證明其成本合理，但許多概念和技能可以轉移到開源替代方案中。
- 可支援性 -簡單地說，它可以正常工作。它具有許多預設值和即用型功能，因此您不必花費大量時間閱讀文件並嘗試使一些沒有明確說明的內容能夠正常工作。
競爭對手：
- ELK Stack - ElasticSearch，LogStash和Kibana，雖然似乎總是很酷，因為它們不向您收取使用費用，但隨著日誌集的增長和機上越來越多的應用程式的維護，它的確變得更加困難您的工具。與使用Splunk相比，我在構建任何型別的儀表板之前花了更多的時間來設定工具。
協作DevOps工具
DevOps首先是組織內部的文化變革。雖然購買工具不會一夜之間改變文化，但無疑可以幫助培養與同事合作的新方法。
協作工具子類別為：
- 問題跟蹤
- 聊天操作
- 文獻資料
2020年排名第一的問題跟蹤工具：Jira
吉拉（Jira）繼續保持頭把交椅，儘管在這個領域競爭日益激烈。但是，Jira內建的強大靈活性使開發團隊和運營團隊可以管理其專案工作和衝刺任務。使用敏捷術語的內建標準有助於緩解從傳統工作方法到更精益流程的文化轉變。
主要優勢:
- 行業標準 — 同樣，就像許多工具一樣，Jira到處都有使用。小型團隊可以使用便宜的許可證並獲得所需的一切，而企業可以為任何人負擔得起許可證。
- 整合 - 在這個領域處於領先地位並且快速增長意味著第三方工具會選擇您首先構建本機整合，而它們只會增加您工具的價值，而Jira就是這種情況。我們可以與現成的列表中的所有其他工具整合，而無需進行任何定製。
競爭對手:
- Trello — Trello成為免費使用的看板工具，因此迅速流行。但是，一旦事情開始擴充套件，並且您從數十個問題擴充套件到數千個問題，Trello將變得難以導航，搜尋和報告。
- Pivotal Tracker - 在初創公司工作期間，我非常喜歡該工具。但是，他們更多地關注產品管理，而不是技術任務。儘管從Jira進行產品管理比較困難，但是仍然可以完成此過程，而不必獲取完全獨立的工具。
2020年排名第一的ChatOps工具：MatterMost
說明：這可能是2020年這份清單上最大的驚喜，這是一件好事！MatterMost通過使用以前最好的工具，但引入了本地部署而獲得了普及。對於企業來說，這是巨大的，因為它可以控制資料，還可以幫助與本地工具整合-我們不再需要為了新的事物而走出防火牆。
主要優勢:
- 開源 - MatterMost的開源版本非常適合小型或大型團隊。與Slack的免費層會丟失歷史記錄不同，您自己執行伺服器意味著您擁有資料。
- 整合 - 因為API幾乎100％基於Slack API，所以幾乎所有Slacks整合都可以直接與MatterMost一起使用。
競爭對手:
- Slack - 鬆弛很棒，但是它們已經變得如此龐大，需要開始獲利。他們業務的付費階段即將到來，並且剝奪了Slack用來免費提供的許多價值，最關鍵的是聊天記錄。
- Microsoft Teams - 嘗試將Microsoft產品與非Microsoft本地產品整合-祝您好運。這就是我要說的！
2020年排名第一的文件工具：Confluence
無論使用哪種工具，都很難建立和維護高質量的技術文件。儘管最近有許多SaaS文件工具進入市場，但我很難接受將有關關鍵應用程式的敏感技術文件儲存給第三方。我需要將資料和文件保留在本地，這就是Confluence為我所做的。
主要優勢：
- 易於管理 - 大多數自託管工具的啟動和執行可能有些複雜，並且大規模維護它們需要一些特定知識。開箱即用的Confluence伺服器非常適合10個使用者或10,000個使用者。
- 外掛－ 儘管建立具有預設融合功能的漂亮且易於瀏覽的文件已經很不錯了，但是擁有用於幾乎所有內容的外掛的能力釋放了Wiki的潛力。
競爭對手：
- Read the docs — 非常適合開源公共程式碼，但永遠不會考慮在這裡儲存關鍵的應用程式知識。
- MarkDown — 儘管非常適合於記錄有關我的程式碼的內容，但很難將體系結構，過程或其他型別的文件直接放入MarkDown格式中。
- Jekyll — 在記錄技術知識時，我並不想簡單地構建一個新的靜態站點，以便在每次更改時進行部署。簡單的Confluence版本管理系統使內部文件的處理變得更加容易。
總結 2020 年最佳
市場上實際上有數百種DevOps工具。試圖瀏覽應使用哪些以及何時實施它們可能會令人不知所措。遵循此簡單指南，為完整的CI / CD管道選擇DevOps工具堆疊。
將工具分為以下五個關鍵領域：
- 開發和構建工具
- 自動化測試工具
- 部署工具
- 執行時工具
- 協作工具
最後希望大家切記：自動化所有能自動化的事情！
部分參考連結：
1. 《Must Learn DevOps Tools for 2020》
2. 《How to create a DevOps roadmap & Treebo’s 9 month DevOps Journey》
3. 《DevOps with AWS》
4. 《 Using this Time to Optimize Your Dev Team’s Workflow》
