本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

開發運維改革終于成為主流，人們對開發運維工具的歡迎程度暴增。根據谷歌趨勢的顯示，“開發運維工具”的搜索量穩定增長，且會繼續保持增長。

由于DevOps包括整個軟件開發周期，可供選擇的工具很多。當然啦，沒有一種工具能適合所有情況。但有幾種工具的性能已經成熟，可以為幾乎所有情況提供廣泛的支持。

成功且成熟地采用開發運維方法，你將始終擁有完整的渠道，這包括適用于五個類別的工具。記住，評估當前的工具堆棧很有必要，確保沒有丟失CI/CD管道的關鍵內容。

開發和構建工具

這是CI / CD管道堆棧的基礎，一切始于此。該類別中最好的工具可以協調多個事件流，并且可以輕松地與外部工具集成。軟件開發生命周期中的工具分為三個子類別：

• 源代碼控制管理 (SCM)
• 持續集成 (CI)
• 數據管理

2020年推薦的源代碼控制管理(SCM)技術是GIT，因此SCM工具必須具有出色的GIT支持;對于持續集成(CI)，需要具備在臨時容器化環境中運行和執行構建的能力;而對于數據管理，需要能夠對數據庫架構進行更改并使它與應用程序版本保持一致的能力。

1. SCM + CI工具：Gitlab和Gitlab-CI

 

 

 

圖源：unsplash

 

Gitlab無疑是最偉大的開發運維周期工具，且它將在可預見的未來成為創新引領者。其核心功能提供了完美的GIT存儲庫管理工具，它基于網絡的用戶界面且易于使用。Gitlab可免費提供所需的一切，并且具有SaaS和On-Prem兩種形式。

市場上有很多SCM工具，但是沒有一種工具像Gitlab那樣將“持續集成”直接集成到存儲庫中的。將一個名為.gitlab-ci.yml的文件粘貼在代碼庫的根目錄中，任何GIT事件都會根據定義的內容觸發操作。

其優點包括：

• 成熟：該產品自2013年以來已投放市場，非常穩定，得到大力支持。
• 開源：Gitlab的免費版本沒有削減開發團隊所需的核心功能。每個付費層都提供了附加功能，這些附加功能基于組織的規模和需求可以帶來極高的價值。
• 根深蒂固的CI：市場上其他工具不能將持續集成直接嵌入到SCM中，而Gitlab-CI工具可以。使用Docker構建進行臨時構建的能力提供了無憂的構建作業，并且內置的報告使調試構建失敗變得容易，無需復雜的集成和編排多個工具。
• 無限集成 ：Gitlab提供了每個核心開發運維類別中所需的輕松集成工具，這使開發人員和操作人員在任何環境中都可以使用真實的來源來獲取與其應用程序相關的信息。

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

• GitHub ：對于小型和早期開發商，GitHub只是一個出色的SaaS源代碼管理系統。但對于需要在網絡中保留其IP的大型企業，GitHub的唯一選擇是 .OVA虛擬機，不支持高可用性，從而難以維護on-prem，只能在服務器本身開始崩潰之前運行于中型組織機構。

GitHub Actions或CI-as-Code的缺乏意味著始終需要帶上自己的CI工具，并管理該集成，而且它比Gitlab定價要貴一些。

• Jenkins：盡管Jenkins已成為持續集成工具的默認標準，但它始終缺少源代碼控制元素。這意味著你得一直使用Jenkins和SCM工具，而GitLab同時提供這兩種功能，這簡直是不必要的復雜。
• BitBucket/Bamboo：它需要兩種工具才能完成Gitlab的一項工作，盡管BitBucket云端支持Gitlab-CI/GitHub Action功能，但沒有一家公司會輕易采用它，用于本地的BitBucket服務器甚至不支持BitBucket管道!

2. 數據管理工具：FlywayDB

網絡應用程序開發中最容易忽視數據庫的自動化需求，通常是對應用程序的新版本部署數據庫架構更改的事后思考，其模式更改通常會添加或重命名列或表。如果應用程序版本與架構版本不匹配，該應用程序可能會完全損壞。

由于存在兩個不同的系統，因此通過應用程序升級來協調數據庫更改也比較困難，而FlyWayDB解決了所有這些問題。

其主要優勢在于：

• 數據庫版本控制：FlyWay允許簡單地創建數據庫版本，跟蹤數據庫遷移以及輕松地前滾或回滾架構更改，無需某些定制解決方案。
• 二進制或內置：可以選擇在應用程序啟動時或二進制執行文件時運行Flyway。在代碼中使用此工具，它能在啟動時檢查版本功能并進行適當的遷移，從而使數據庫和應用程序版本保持同步。還可以臨時運行命令行，為現有數據庫提供靈活性，無需重建整個應用程序。

該領域沒有很多工具只有兩個競爭對手可以看看:

• LiquiBase ：如果對該工具有更多經驗的人，那么我非常樂意通過FlyWay將該工具標準化。
• Flocker ：這可能僅適用于容器化的應用程序——在容器中運行數據庫非常困難，必須精心計劃才能成功執行。建議將RDS之類的服務用于數據庫，而不要嘗試運行存儲在容器中的關鍵數據。

自動化測試工具

首先將自動化工具安裝到測試金字塔中，進而開始對自動測試工具進行評估，測試有四個方面：

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

1. 集成測試工具: Cucumber

Cucumber將規范和測試文檔合并為一個緊密結合的有效文檔。由于它們是由Cucumber自動測試的，因此規格總是最新的。

如果要開始構建網絡自動化測試框架，并模擬網絡應用程序上的用戶行為，具有Java和Cucumber BDD的Selenium WebDriver是在項目中學習和實現Cucumber的好方法。

其主要優勢在于：

• 基于行為驅動的開發：Cucumber用于BDD測試，它已成為一種測試框架(與傳統基于測試驅動的開發相比)。
• 有效的文檔 ：記錄所做的事情總是很痛苦的。由于你的測試被定義為代碼，因此Cucumber測試會自動生成文檔進行匹配以確保它們始終保持同步。
• 支持：有很多工具可供選擇，但總需要維修者來幫幫忙。Cucumber擁有足夠的資金和支撐結構在未來幾年維護該工具。

該領域有許多框架和特定技術的工具，但是只有Cucumber幾乎是萬能的解決方案。

端對端測試工具

進行端到端測試時，有兩個重點領域需要關注：功能測試和負載測試。

功能測試顯然是在測試幻想發生且實際發生的事情。當單擊SPA上的某些頁面，填寫表格并單擊提交時，數據顯示在數據庫中，并且屏幕會顯示成功的字樣。

還需要能夠測試在相同場景下工作的x數量的用戶是否可以正確處理。如果在這兩個方面都沒有進行測試，CI / CD管道中的差距將很大。

1. 端到端測試工具—功能：SoapUIPro

自默認SOAP網絡服務開始，SoapUI進入API測試領域已有很長時間了。雖然不再構建新的SOAP服務，也沒有更改該工具的名稱，但這并不意味著它沒有發展。

SoapUI為構建后端網絡服務的自動化功能測試提供了一種出色的結構。這些可以輕松地與持續集成工具結合，并作為CI/CD管道的一部分運行。

其主要優勢在于：

• 廣泛的文檔：此工具已經存在了一段時間，因此有許多線上資源可幫助確定如何配置負載測試。
• 易于使用：雖然有幾種適用的API測試工具，但一個接口用于多種服務，會使測試構建變得簡單。

其競爭對手有Selenium：Selenium是該領域的出色工具，建議在構建和運行基于Java的應用程序時使用。但如果正在使用多種技術來處理一個完整的網絡應用程序，使用非Java語言可能會有些笨拙。

2. 端到端測試工具—負載測試：LoadRunner

 

只有LoadRunner才能完成對應用程序各個方面的負載測試。雖然價格昂貴而且入門有些困難，但它是唯一可以執行測試的工具。作為一名技術架構師，筆者相信新代碼將在極端壓力下執行。

其主要優勢在于：

• 廣泛的文檔：該工具也已經存在了一段時間，有豐富的在線資源。
• 協議支持：從ODBC到AJAX，再到HTTPS以及可能在某處使用的其他隱晦協議，負載測試都支持該協議。要避免串接多個負載測試工具，這只會增加復雜性。

同樣，該領域并沒有很多萬能的工具，簡單的解決方案是可以在任何環境中使用。

部署工具

部署工具可能是應用程序開發中鮮為人知的方面。對于操作人員來說，如果不深入了解應用程序代碼和功能，就很難使用部署工具。而對于開發人員來說，管理代碼部署是一項新的職責，他們很少有使用許多部署工具的經驗。

1. 構件管理工具: Nexus

Nexus工件存儲庫支持從Java到NPM再到Docker幾乎所有主要的技術，可以使用這一工具來存儲所有可部署的工件。

通過使軟件包更接近構建過程，代理遠程軟件包管理器的能力大大提高了CI配置的速度。這樣做的另一個好處是可以全局查看跨多個軟件項目用途的軟件包，從而鎖定不安全的開源軟件包，這可能是代碼中的攻擊媒介。

其主要優勢在于：

• 技術支持：該產品自2013年投放于市場上，一直都非常穩定，獲得了良好支持。
• 開源：免費版的Gitlab并沒有削減開發團隊所需的核心功能。每個付費層均提供附加功能，這些附加功能可帶來最大價值，具體取決于組織的規模和需求。

2. 配置管理工具: Ansible

Ansible是這個領域的引領者，原因很簡單：無狀態。早期的現場配置管理工具著重于管理配置狀態。如果它與所需的配置脫離同步，將自行修復。新的應用程序只有無狀態組件。

其主要優勢在于：

• 無狀態：Ansible playbooks運行于操作機器上。筆者不在乎遠程對象的狀態，使用Packer之類的工具來構建可部署對象變得更加容易。
• 開源：與CentOS一樣，RedHat也維護Ansible。該企業及其高級支持人員可以幫助維護社區，并確保高質量、易于使用的模塊。
• 分子測試：由于配置管理與其他任何代碼一樣，如果不對其進行測試將無法開始操作。用于測試Ansible角色的分子框架可以無縫地工作，以確保代碼配置的高質量，并遵循與應用程序代碼相同的CI/CD管道。
• YAML：與其他工具相比，YAML更容易讓人頭腦清醒。通常來說，配置管理對于采用開發運維的任何人都是新事物。

其競爭對手有以下兩個：

• OpsCode Chef：筆者是以chef cookbook開發人員的身份開始開發運維生涯的。Ruby和Chef十分相近，但是它們根本無法解決目前無狀態、云原生應用程序的問題。對于更傳統的應用程序來說，這是一個不錯的工具，但本文著眼于未來。
• Puppet：Puppet從未發展過龐大的社區，尤其與Chef 和Ansible相比而言。它非常適合配置和裸機，但不支持網絡應用程序類型的配置管理。

3. 部署工具：Terraform

Terraform解決了從網絡組件到實際服務器圖像的基礎架構，即代碼定義問題。自最初發布以來，它已經發展了一段時間，并建立了龐大的插件社區和支持社區，為可能遇到的幾乎所有部署情況提供幫助。支持本地環境、云環境或其他任何類型環境的能力是首屈一指的。

最后，與任何其他傳統的編程語言一樣，最新版本在HCL中提供了相同的邏輯功能和類，開發人員可以輕松獲得和學習。

其主要優勢在于：

• 不可知的云/環境：Terraform利用其代碼與所有API和后端邏輯之間的接口，這些API和后端邏輯是基礎架構提供商進行通信所需的。
• 開源：免費工具也很難做到，其社區支持是一流的。

其競爭對手有AWS Cloud Formation：即使僅在AWS云環境中工作，你也可能會向未知的方向繼續前進，將技能和知識整合到一個平臺中可能會有風險。另外，許多新AWS服務通常在用于CloudFormation之前作為Terraform模塊提供。

開發運維工具運行

任何開發項目的最終目標都是在生產中運行應用程序。在開發運維領域中，要確保我們對該環境中的任何潛在問題具有可見性，并且將人工干預降至最低。選擇正確的運行時工具集對于實現發展至關重要。

1. 工具即服務：AWS

亞馬遜一直是云計算領域的引領者。它們也不僅止步于此，還提供了許多新服務供開發人員利用，讓人眼花繚亂。將任何技術和任何模式帶到AWS上，它就可以被構建和運行。

與在自己的數據中心中構建、管理和維護傳統硬件相比，它們的成本極其合理。免費服務使任何人都有機會先進行嘗試，再做出購買決定，這對嘗試以正確的方式構建應用程序非常有用，而不是因為成本而不得不妥協。

其主要優勢在于：

• 行業標準：如果有在AWS中構建應用程序的經驗，那么基本上可以在任何地方找到工作。企業喜歡AWS，而創業公司喜歡AWS的低成本。
• 免費服務：與其他所有內容相比，這是AWS擁有的極其正確的業務。先使用該服務并知道其工作原理，然后再決定將數千美元投入可能的巨大陷阱中。

其競爭對手有以下幾個：

1. Azure：自發布以來，Azure已經有所發展。但是，區分自身的需求導致其對服務進行了奇怪的命名，而這些服務讓人難以了解——到底什么是“ 云端的文件系統”。盡管.NET代碼在微軟生態系統中效果更好，但在應用程序的各個方面只使用.NET是不可能的。
2. Heroku：除了在Heroku上運行個人項目之外，筆者不會運行任何其他項目。它的透明度不高，企業沒有理由將其用作平臺。這對演示博客中的內容非常有用，但是對實際應用程序不太友好。

2. 編制工具:OpenShift

你可能在應用程序堆棧中的某處使用了Docker或Container。無服務器的應用程序雖然不錯，但不能適應所有架構模式。在沒有業務流程平臺的情況下運行容器根本行不通。

從安全性和工具角度來看，Core Kubernetes帶來了很多需求。OpenShift是唯一的Kubernetes平臺，它具有Source2Image構建，pod中的部署自動化，甚至有可追溯性和監視功能。它可以在本地，云中或同時在兩者中運行。

其主要優勢在于：

• 內置安全性：管理K8安全性幾乎需要博士學位。默認情況下，OpenShift所采用的安全機制減少了開發人員的工作量，并為他們的應用程序提供了更安全的平臺。
• 多合一解決方案：與默認不包含負載平衡工具的基礎型K8不同，OpenShift擁有所有功能?？梢杂盟鼇硗泄蹸ontainer，構建Container，運行CI/CD工具，編排外部流程，管理機密等等。盡管GUI仍然需要做更多的工作，但API優先的方法意味著一切都可以進行編寫，并且與K8的其他GUI不同，它使學習Kubernetes基礎知識變得更加簡單，無需以獲得該學位為首要任務!

其主要競爭對手是Docker Swarm：Dockerswarm試圖刪除很多東西來簡化K8。這對于較小的應用程序非常有用，但對于企業應用程序根本不起作用。此外，AWS ECS之類的服務采用了類似的方法，卻使正在交互的其他服務(Lambda、IAM等)使用起來更簡單。

3. 監控工具: NewRelic

New Relic的早期發行成功地實現了APM監控?，F在，它是一套完整的監控工具，可以監控服務器性能，容器性能，數據庫性能，以及進行最終用戶體驗監控，當然還有APM監控。

其主要優勢在于：

• 易于使用：在擔任系統工程師的時候，我曾使用過許多監控工具，但都不如NewRelic這樣易于使用。這是一種軟件服務(SaaS)，無需設置服務器組件，十分便捷。 
• 端到端可見性：其他工具試圖監控應用程序的某個特定方面。無論是CPU利用率還是網絡流量，這些都可以協同工作，使應用程序正常運行。NewRelic使你能夠整合所有數據，真實了解正在發生的事情。

其競爭對手有以下幾個：

• Zabbix：Zabbix是筆者第一個最喜歡的監控系統，但是它不能發展到原生云版本，而且APM空間使它發展滯后了。不過，它仍然可以很好地監控傳統的服務器基礎結構。
• DataDog：該工具過多地側重于管理生產應用程序的過程，而忽略代碼本身。在有開發人員參與生產的開發運維團隊中，無需依靠繁瑣的工具來提供頂級的支持。

4. 記錄工具: Splunk

他們長期以來一直是日志聚合的領跑者，并且會繼續努力做到最好。借助本地和SaaS產品，可以在任何地方使用它。它的主要缺點是運行的成本很高。

其主要優勢在于：

• 行業標準：企業喜歡使用Splunk，他們也有資金來支付。雖然初創企業可能難以承擔其成本，但許多概念和技能可以轉移到開源替代方案中。
• 可支持性：它具有許多默認設置和即用型功能，因此不必花費大量時間閱讀文檔并嘗試使用一些沒有明確說明的內容。

其主要競爭對手是ELKStack：ElasticSearch、LogStash和Kibana似乎很受歡迎，因為它們不收取使用費用，但隨著日志集的增多以及工具中越來越多的應用程序，確實會變得更加難以維護。與使用Splunk相比，在構建任何類型的儀表板之前，你會花更多的時間來設置工具。

協作開發運維工具

開發運維首先是組織內部的文化變革。雖然購買工具不會一夜之間改變文化，但無疑可以幫助培養與同事合作的新方式。

1. 問題跟蹤工具：Jira

盡管該領域的競爭日益激烈，但Jira仍然保持領先地位。但Jira內置的強大靈活性使開發團隊和運營團隊可以管理其項目工作和沖刺任務，使用敏捷術語的內置標準有助于緩解從傳統工作方法到更加精益的流程的文化轉變。

其主要優勢在于：

• 行業標準：與許多工具一樣，Jira基本在各地都有使用。小型團隊可以使用便宜的許可證并獲得所需的一切，而企業能為任何人承擔許可證。
• 集成：在該領域處于領先地位并且快速增長意味著第三方工具會選擇首先構建本機集成，而它們只會增加工具的價值，Jira就是這種情況?？梢耘c現有列表中的所有其他工具集成，幾乎不需要進行定制。

其競爭對手有以下幾個：

• Trello：Trello成為免費使用的Kanban工具而迅速流行。但當從數十個問題擴展到數千個問題，Trello會變得難以控制、搜索和進行報告。
• Pivotal Tracker：在為初創公司工作時，筆者非常喜歡這個工具。但他們更多地關注產品管理，而不是技術任務。盡管通過Jira進行產品管理比較困難，但是仍然可以完成此過程，無需獲取完全獨立的工具。

2. 聊天運營工具:MatterMost

這可能是2020年清單上最大的驚喜。MatterMost使用了以前最好的工具，引入了本地部署，獲得了廣泛的歡迎。對于企業來說是巨大的好處，因為它可以控制數據，還有助于與本地工具集成。

其主要優勢在于：

• 開源：MatterMost的開源版本非常適合小型或大型團隊。不同的是，在Slack的免費服務中如果丟失歷史記錄，運行服務器意味著找回數據。
• 集成：由于該API幾乎100%基于Slack API，所以幾乎所有Slacks集成都可以直接與MatterMost一起使用。

其競爭對手主要有以下兩個：

• Slack：Slack真的很不錯，但它們已經發展迅猛，需要開始盈利。他們業務的付費階段即將到來，Slack曾經免費提供的許多功能開始需要付費，包括聊天記錄。
• 微軟團隊：嘗試將微軟產品與非微軟本地產品集成的話，祝你好運。

3. 文檔工具:Confluence

無論使用哪種工具，都很難創建和維護高質量的技術文檔。盡管最近有許多SaaS文檔工具進入市場，但將關鍵應用程序的敏感技術文檔存儲給第三方這一點讓人難以接受。需要將數據和文檔保留在本地，這就是Confluence的作用。

其主要優勢在于：

• 易于管理：啟動大多數自托管工具可能會有些復雜，而且大規模地對其運行和維護需要一些特定的知識。開箱即用的Confluence服務器可以適用于10個或10000個用戶。
• 插件：盡管創建具有默認融合功能的、美觀且易于瀏覽的文檔已經很不錯了，但是擁有用于幾乎所有內容的插件功能激發了Wiki的潛力。

其競爭對手有以下幾個：

• Read the docs：非常適合開源公共代碼，但是從不考慮存儲關鍵的應用程序知識。
• MarkDown：雖然非常適合于記錄有關代碼的事情，但很難將體系結構，過程或其他類型的文檔直接放入MarkDown格式中。
• Jekyll：在記錄技術知識時，希望構建一個新的靜態站點，以便在每次更改時進行部署。簡單的Confluence版本管理系統使內部文檔更加易于處理。

市場上有數百種開發運維工具，瀏覽篩選應該使用的工具以及它們的執行時間是大勢所趨。遵循本指南，為完整的CI/CD管道選擇開發運維工具堆棧吧。

關鍵是要記住，將一切事物自動化!