2020年 DevOps 領域值得推薦的工具-網絡運維
2020-06-10 21:33 作者：admin
2020年 DevOps 領域值得推薦的工具-網絡運維
網絡運維 保姆級的IT外包,2小時內上門,專業工程師7*24h隨叫隨到,提供整體的IT解決方案,兼職網管,桌面運維,it外包
從今天開始，讓我們使用最佳 DevOps 工具。
DevOps 革命已然成為主流，各類 DevOps 工具的人氣一路飆升。根據 Google Trends 的統計，互聯網用戶對“DevOps 工具”的搜索量一直在穩定增長，而且整體發展趨勢也相當穩定。
由于 DevOps 涵蓋整個軟件開發生命周期，期間涉及多種可選工具選項。沒有哪種工具能夠適合所有情況，但是針對各類應用場景都有對應的、發展較為成熟的工具。我們把整個 DevOps 實踐過程中使用到的工具分為以下幾類：
· 開發與構建工具
· 自動化測試工具
· 部署工具
· 運行時 DevOps 工具
· 協作 DevOps 工具
一個成熟且成功的 DevOps 實踐必須建立一套完整的工具管道，以上五類工具就包含在其中。
小程序開發1. 開發與構建工具
這類工具是 CI/CD 管道堆棧的基礎，一切也以此作為起點。開發與構建工具需要協調多個事件流，并能與外部工具輕松集成。根據軟件開發生命周期，這類工具又可以分為三個子類別：
· 源代碼控制管理（SCM）
· 持續集成（CI）
· 數據管理
2020 年，我們最推薦的 SCM 技術是 Git，所以建議選擇的 SCM 工具最好提供出色的 Git 支持能力。在 CI 方面，最重要的是在臨時容器化環境中運行及執行構建任務的能力。至于數據管理，我們希望工具能夠變更數據庫架構，并使其與應用程序版本保持一致。
SCM+CI工具：Gitlab與Gitlab-CI
Gitlab 無疑是 2020 年最強大的 DevOps 生命周期工具，并將在可預見的未來將成為創新領域的領導者。
Gitlab 的核心定義是在于提供一款完美的 Git repo 管理工具，其基于 Web 的用戶界面詳盡且易于使用。更重要的是，即使是 Gitlab 的免費版本也足以解決用戶的各類需求，且分別提供 SaaS 與本地設施版本。
目前市面上的 SCM 工具多種多樣，但沒有哪位競爭者能夠像 Gitlab 那樣多年來一直堅持將“持續集成”能力引入 repo 當中。我們只需要將.gitlab-ci.yml 文件粘貼至 repo 的根目錄當中，Gitlab-CI 即可根據用戶在文件中作出的定義觸發各類操作。總而言之，這兩款工具彼此配合、成為代碼持續集成領域當之無愧的領導者。
主要優勢
成熟—該產品于 2013 年正式投放市場，表現穩定且提供良好的支持服務。
開源— Gitlab 的免費版本并沒有削減開發團隊所需要的各項核心功能。而不同付費選項又進一步提供了更多附加功能，可根據組織的具體規模與需求帶來更大的價值。
易用且強大的 CI— 目前市面上沒有哪款工具能夠像 Gitlab-CI 一樣將持續集成直接嵌入 SCM 當中。用戶可以利用 Docker build 輕松完成構建任務，內置報告功能也讓 build 故障調試變得簡便易行。總之，無需復雜的集成與業務流程，即可對多種必要工具進行編排。
無限集成— Gitlab 還能輕松集成 DevOps 各核心類別中的不同工具選項。如此一來，開發人員與運營人員將可立足任意環境通過真實來源獲取與其應用程序相關的信息。
與競爭對手的比較
市面上的同類工具有很多，但大多無法與 Gitlab 相比肩。
GitHub — GitHub 是一套面向小型及早期開發群體的 SaaS 源代碼管理系統，但對于需要在網絡當中保留知識產權資產的大型企業，GitHub 提供的唯一選項只有.OVA 虛擬機。由于這款工具不支持高可用性保障，on-prem 部署的維護難度會比較高，且在業務規模增長到一定程度后必然引發服務器崩潰。另外，GitHub Actions（最近剛剛推出，但仍不提供本地版本）與 CI-as-Code 的長期缺席，迫使用戶自行準備 CI 工具以管理集成。最后，GitHub 的使用成本要遠高于一切 Gitlab 版本。
Jenkins — 雖然 Jenkins 已經成為持續集成工具中的默認標準，但它卻始終缺少源代碼控制元素。換句話說，Jekins 一直無法與 SCM 工具真正統一起來。相比之下，Gitlab 這樣的工具能夠同時兼顧這兩大功能，消除不必要的復雜性因素。另外，與目前的現代 Web 應用程序相比，Jenkins 糟糕的用戶體驗可能讓很多朋友不堪忍受。
BitBucket/Bamboo — 恕我直言，在大家考慮使用兩種工具來完成 Gitlab 本身就能完成的任務的同時，這套方案就已經落入下風了。雖然 BitBucket 云已經能夠支持 Gitlab-CI/GitHub Action 功能，但還沒有哪家成熟企業（超過初創公司的規模）能夠輕松進行部署與使用。更夸張的是，本地版本的 BitBucket 服務器甚至不支持 BItBucket Pipelines！
2020 年頭號數據管理工具：FlywayDB
Web 應用程序開發中最容易被忽視的方面就是數據庫的自動化需求。人們往往是事后才想起需要為應用程序的新版本部署數據庫 schema 變更。Schema 變更往往會添加或重命名多個列或表。如果應用程序版本與 schema 版本不匹配，還有可能徹底破壞應用程序的正常運行。最后，由于存在兩套不同的系統，通過應用程序升級來協調數據庫變更也比較困難。好消息是，FlyWayDB 自己就足以解決以上所有的問題。
主要優勢
數據庫版本控制 — FlyWay 允許用戶輕松創建各數據庫版本、跟蹤數據庫遷移并輕松完成 schema 變更的前滾與回滾——整個過程無需配合定制構建解決方案。
二進制或內置—大家可以選擇在應用程序的啟動過程中、或者以二進制可執行文件的形式運行 Flyway。用戶可以在代碼中直接使用此工具，使其在啟動時能夠檢查版本功能并運行適當遷移，從而令數據庫與應用程序的版本保持同步。當然也可以臨時運行 cmd 行，在無需重建整體應用程序的前提下為現有數據庫提供良好的靈活性。
與競爭對手的比較
與 FlyWay 處于同一定位的競爭對手不太多，但我們仍有必要分析雙方的實力差距：
LiquiBase — Liquibase 跟 FlyWay 非常相似。事實上，如果能找到經驗豐富的專項負責人員，我其實更傾向于將 LiquiBase 選定為標準解決方案。
Flocker — 這款工具更多強調對容器化應用程序的管理——相信很多朋友都有切身體會，在容器當中運行數據庫往往非常困難，需要精心規劃才能達成目標。我建議大家使用 RDS 這類數據庫服務，最好不要輕松嘗試在容器之內運行關鍵數據存儲。
小程序開發2. 自動化測試工具
我們首先需要將自動化工具引入整個測試“金字塔”體系，然后才能對自動測試工具進行評估。
整個測試金字塔分為 4 層：
· 單元測試 — 這是所有自動化測試的基礎。單從數量角度來看，單元測試的數量應該遠遠高于其他測試類型。單元測試應由軟件開發人員負責編寫與運行，以確保應用程序中的特定組成部分（即「單元」）符合設計要求并能夠按照預期方式運行。
· 組件測試 — 組件測試的主要目標在于驗證測試對象的輸入 / 輸出行為。這能確保測試對象的功能以符合必要規范的形式正常運作。
· 集成測試 — 在這一測試階段，我們需要將各個軟件模塊組合起來并共同進行測試。
· 端到端測試 — 這一層的測試目標非常明確了，我們需要從頭到尾跟蹤應用程序流程，保證其與預期結果保持一致。
由于單元與組件層測試單純由應用程序開發人員負責，且通常根據具體編程語言而有所區別，因此這部分工作不在 DevOps 的討論范圍之內。
2020 年頭號集成測試工具：Cucumber
Cucumber 將規范與測試文檔合并為統一的動態文件。Cucumber 能夠自動完成測試，因此能夠保證用戶規范將始終保持更新。如果大家希望構建 Web 自動化測試框架并在 Web 應用程序之上模擬用戶行為，不妨在項目當中使用帶有 Java 與 Cucumber BDD 的 Selenium WebDriver——這將是您學習并實現 Cucumber 測試功能的良好起點。
主要優勢
行為驅動型開發（BDD） — 適用于 BDD 測試，而且已經成為這一領域中的首選測試框架（相較于傳統測試驅動型開發）。
動態文件 —文檔記錄一直是項令人頭痛的工作，但在以代碼形式對測試內容進行定義之后，Cucumber 測試可以自動生成文件以匹配測試需求，并保證各項需求始終保持同步。
支持 —目前市面上有多種支持工具可供選擇，但對于規模較大的嚴肅項目來說，工具維護者的態度將決定方案的可靠性與可持續性。Cucumber 團隊擁有充足的資金與支持架構，足以在可預見的未來保持這款工具的健康發展。
與競爭對手的比較
這一領域中有著多種框架與面向特定技術場景的工具，但只有 Cucumber 最接近“普適性”解決方案的層次。
2020 年頭號端到端測試工具
進行端到端測試時，我們需要重點關注以下兩個核心問題：
· 功能測試
· 負載測試
功能測試，顧名思義是要測試我們需要的一切是否按預期正常發生。在點擊 SPA 上的某些頁面、填寫不及格并單擊 Submit 時，數據將顯示在數據庫當中，且屏幕顯示提交成功！
此外，我們還需要測試在同一場景下，數量為 x 的用戶發出的同時操作是否得到了正確處理。
如果缺少這兩種重要的測試類型，最終 CI/CD 管道運行表現將出現巨大差異。
功能測試：SoapUI Pro
SoapUI 在 API 測試領域已經擁有相當豐富的積累，這主要受益于 SOAP Web 服務的默認地位。雖然我們已經不再構建新的 SOAP 服務，但這款工具的名稱并未因此改變，且仍在向著用戶的實際需求不斷發展。SoapUI 為后端 Web 服務的自動化功能測試提供了一整套出色的構建架構，其中一切元素都能輕松與持續集成工具將結合，作為 CI/CD 管道中的組成部分協同運行。
主要優勢
廣泛的文檔資源 — 這款工具已經存在了多年時間，因此大家可以在網上輕松找到用于指導負載測試配置的學習資源。
易用性—盡管目前市面上的 API 測試工具有很多，但 SoapUI 在單一服務中囊括了多種服務接口，從而讓測試構建變得更加簡單。
與競爭對手的比較
Selenium — Selenium 是另一款重要的測試工具。如果您正在構建并運行基于 Java 語言的應用程序，那么我們其實更推薦 Selenium。但是，如果您的訴求在于使用多種技術處理同一款完整的 Web 應用程序，那么 Selenium 在非 Java 語言用戶手中顯得有些笨拙。
負載測試：LoadRunner
在對應用程序中各個層面進行負載測試時，LoadRunner 表現出了無可替代的全面優勢。雖然 LoadRunner 價格較高且難于上手，但它卻是唯一能夠模擬出極端壓力環境、并真正讓技術架構師們對新代碼建立起充分信心的測試工具。另外，我也覺得是時候將負載運行技巧從 SQA 資源轉移到開發團隊當中。
主要優勢
廣泛的文檔資源 — 這款工具已經存在了多年時間，因此大家可以輕松在網上找到用于指導負載測試配置的學習資源。
協議支持 — 從 ODBC 到 AJAX、再到 HTTPS 乃至應用程序偶爾使用的其他晦澀協議，LoadRunner 總能提供良好的支持能力。相比之下，為了協議支持而同時使用多種負載測試工具只會增加整個流程的復雜性。
與競爭對手的比較
同樣的，在測試市場上并沒有百試百靈的工具，因此能夠不太費心地引入當前環境并直接使用的技術就算是好技術了。
小程序開發3. 部署工具
在應用程序開發當中，部署工具往往受到人們的嚴重忽視。但對運營人員而言，如果不深入了解應用程序的代碼與功能，將很難順利使用部署工具；在另一方面，開發人員則開始越來越多地承擔起代碼部署的職責，因此需要盡快積累原本匱乏的部署工具使用經驗。
首先，我們將部署工具分為三個子類：
· 構件管理
· 配置管理
· 部署
2020 年頭號構件管理工具：Nexus
Nexus 構件存儲庫支持幾乎所有的主要技術，包括 Java、NPM 乃至 Docker 等等。我們可以使用這款工具來存儲所有的可部署構件，通過拉近軟件包與構建流程之間的距離，Nexus 提供的遠程軟件包管理器代理功能極大提升了持續集成速度。這種作法的另一大優勢，在于幫助用戶全局查看跨多個軟件項目使用的全部軟件包，從而鎖定不安全的開源軟件包，避免這些軟件包成為惡意人士攻擊代碼的載體。
主要優勢
技術支持 — 自 2013 年投放市場以來，Nexus 一直擁有穩定的表現并得到開發團隊的良好支持。
開源 — Nexus 的免費版并沒有削減開發團隊所需要的各項核心功能。而不同付費選項又進一步提供更多附加功能，可根據組織的具體規模與需求帶來更大的價值。
2020 年頭號配置管理工具：Ansible
Ansible 是這一領域中絕對的王者，理由非常簡單：無狀態。早期配置管理工具著重于管理配置狀態，換句話說，如果當前狀態與所需配置狀態不再同步，則需要進行修復。但在新型應用程序當中，我們面對的是大量無狀態組件，新版本的代碼屬于新的構件，并用于部署并替換現有構件。整個業務流程將由眾多生命周期短暫的即席環境組成。
主要優勢
無狀態 — Ansible playbook 將由操作機器運行，并直接命中服務器目標。我們不在乎遠程對象的狀態，這讓用戶得以輕松通過 Packer 等工具構建出可部署對象。
開源 — 與 CentOS 類似，Ansible 同樣由紅帽公司負責維護。紅帽在業界擁有良好聲譽，其高級支持人員在維護社區方面擁有豐富經驗，并確保 Ansible 持續提供各類高質量且易于使用的模塊。
分子測試—配置管理本身與正常編寫出的代碼無區別，因此如果不對其進行測試，我們的測試目標也將無從談起。用于測試 Ansible 角色的分子框架能夠無縫運作，確保我們的測試配置能夠切實滿足代碼測試的需求，且同樣遵循應用程序代碼使用的同一 CI/CD 管道。
YAML — 與其他工具相比，YAML 的入門門檻更低。對于大多數剛剛接觸 DevOps 的朋友來說，配置管理都是前所未見的新鮮體驗，因此上手難度越低、就越容易被人們所接受。
與競爭對手的比較
OpsCode Chef — 其實我個人的 DevOps 職業生涯就是從 OpsCode Chef 起步的。Ruby 與 Chef 都是我的心頭好。但必須承認，二者根本沒有應對當前無狀態云原生應用程序問題的能力。當然，對于較為傳統的遺留應用程序來說，這仍是一款很好的工具；但就本文討論的應用場景，我們還是更多著眼于未來。
Puppet — Puppet 一直缺少成規模的技術社區，因此在支持能力方面完全無法與 Chef 以及 Ansible 相提并論。Puppet 雖然非常適合配置與裸機使用場景，但卻無法支持 Web 應用程序類型的配置管理需求。
2020 年頭號部署工具：Terraform
Terraform 解決了在網絡組件到實際服務器鏡像等各類場景當中，如何定義基礎設施即代碼這個問題。自最初發布以來，Terraform 已經經歷了一段時間的發展，并建立起龐大的插件生態與支持社區，能夠為用戶可能遇到的幾乎所有部署場景提供良好幫助。Terraform 擁有對本地、云端或其他類型運行環境的強大支持能力。最后，其最新版本還在 HCL 當中提供多種與其他傳統編程語言相同的邏輯函數與類，這進一步降低了開發人員的上手與學習難度。
主要優勢
云 / 環境中立性 — Terraform 能夠在 Terraform 代碼與基礎設施供應方通信時所必需的 API 及后端邏輯之間充當接口，這意味著只要學習這一款工具，就能隨處實現其部署功能。
開源 — 同樣的，相信沒人能對免費的工具說不，更遑論 Terraform 還擁有良好的支持社區。
與競爭對手的比較
AWS CloudFormation — 即使大家僅在 AWS 環境中工作，也可以規劃自己的學習路線，而并不一定把所有希望都寄托在 AWS 服務家族身上。事實上，把所有技能與知識都放進同一個籃子只會增加職業風險。另外，AWS 的不少新服務在與 CloudFormation 正式對接之前，都會以 Terraform 模塊的形式存在一段時間。
小程序開發4. 運行時 DevOps 工具
任何開發項目的最終目標都是在生產環境中運行應用程序。在 DevOps 領域，我們當然希望保證對環境中的一切潛在問題保持可見性，同時將人工干預程度降至最低水平。為此運行時工具集的正確選擇就成為了良好開發流程必不可少的條件。
運行時工具分為以下幾個子類：
· X 即服務
· 編排
· 監控
· 日志記錄
2020 年頭號 X 即服務工具：AWS
亞馬遜一直是云計算領域的領導者，他們不斷為開發人員提供更多新的服務選項，保持整個體系的新陳代謝。如今，我們可以將幾乎一切技術及模式引入 AWS，進而完成構建與運行工作。與在自有數據中心內構建、管理及維護傳統硬件相比，云服務模式的成本更為合理。免費服務層讓每個人都有機會在實際購買之前先體驗使用感受，并快速摸索出構建應用程序的正確途徑。更重要的，擺脫了自主采購的壓力，擺脫了以往因預算有限而被迫做出的種種妥協。
主要優勢
行業標準 — 如果大家曾經在 AWS 當中構建過應用程序，那么相關工作經驗足以支撐您在任何行業找到立足之地。
免費層 — AWS 最突出的特色在于他們在業務層面從不犯錯。他們允許用戶試用服務并了解其工作原理，然后再決定是否投入資金來批量使用他們提供的解決方案。這種“先嘗后買”的形式非常科學，我自己就從來沒有貿然購買過未經過概念驗證的 AWS 產品。
與競爭對手的比較
Heroku — 簡而言之，除了個人項目之外，我永遠不會把 Heroku 用在嚴肅的開發環境當中。它的透明度實在有限，企業沒有理由選擇這樣一套平臺。除了博文當中進行簡單演示之外，我拒絕對 Heroku 進行任何實際層面的應用。不用，謝謝！
2020 年頭號編排工具：OpenShift
大家可能已經在自己的應用程序堆棧當中使用了 Docker 或者容器技術。無服務器應用程序很棒，但顯然不可能適合所有的架構模式。例如，在沒有業務流程平臺的情況下，我們根本就沒辦法使用容器。而從案例性與工具豐富度的角度來看，Core Kubernetes 的限制因素也比較多。OpenShift 是目前唯一提供 Kubernetes 平臺的服務方案，其中包含 Source2Image 構建、pod 內自動化部署乃至可回溯性與監控功能。更重要的是，它能夠在本地、云端乃至二者兼有的情況下運行。
主要優勢
內置安全保障 — K8s 安全性很難管理，甚至可能需要具備相應博士學位的技術人來管理。而在默認情況下，OpenShift 所采用的安全機制能夠極大減少開發人員的工作量，并為他們的應用程序提供更加安全的平臺。
多合一解決方案 — 與默認不包含負載均衡工具的原始版 K8s 不同，OpenShift 提供所有必要功能。我可以使用它托管自己的容器、構建容器、運行 CI/CD 工具、協調外部流程、管理 secrets 等等。盡管目前的 GUI 還不夠完善，但 API 優先的方法意味著所有內容都能夠以腳本形式實現；而且與其他 K8s GUI 不同的是，OpenShift 使得 Kubernetes 的基礎知識學習過程變得更為簡單。不用博士學位了，大家歡呼起來！
與競爭對手的比較
Docker Swarm — Docker swarm 的本意是刪除大量內容以簡化 K8s 體系。雖然它在體量較小的應用程序中效果不錯，但對于企業級應用程序則根本不起作用。此外，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 同樣有著令人難以拒絕的魅力。長期以來，Splunk 一直是日志聚合領域的領導者，同時也在努力維持自己的統治地位。借助本地與 SaaS 產品版本，用戶已經能夠隨時隨地享受由它帶來的便利。但 Splunk 也不是沒有缺點——它難以運行的老毛病到現在也沒能根治。
主要優勢
行業標準— 企業喜歡 Splunk，也擁有充足的財力使用這套解決方案。雖然初創企業往往難以證明 Splunk 的成本合理性，但其中的不少概念與功能已經在開源替代方案中實現了。
支持效果— 簡單來說，Splunk 能用、而且效果不錯。其中提供多種默認的設置與即用型功能，大家無需投入大量時間閱讀文檔或者反復試錯，即可讓 Splunk 發揮其應有的作用。
與競爭對手的比較
ELK Stack — ElasticSearch、LogStash 以及 Kibana 似乎都挺酷的，畢竟它們不會向用戶收取任何費用；但隨著日志集的增長與應用程序數量的提升，我們越來越難以依靠內置工具維護這些日志記錄方案。與 Splunk 相比，這類工具永遠要耗去更多學習和上手的時間，之后才能構建起正常可用的儀表板。
小程序開發5. 協作 DevOps 工具
DevOps 的第一步就是在組織內部掀起一波文化變革。雖然外來工具不可能在一夜之間改變文化傳統，但卻能夠幫助我們培養起與同事協作的新方法。
協作工具分為以下幾個子類：
· 問題跟蹤
· ChatOps
· 文檔
2020 年頭號問題跟蹤工具：Jira
盡管這一領域的競爭變得日益激烈，但 Jira 仍然穩坐頭把交椅。Jira 內置的強大靈活性足以幫助開發團隊與運營團隊輕松管理項目中的日常工作與沖刺任務。另外，內置的標準敏捷術語也有助于企業逐步完成由傳統工作方法到精準流程文化的轉變。
主要優勢
行業標準—與之前提到的多種其他工具一樣，Jira 的應用范圍極廣。小型團隊可以使用價格低廉的許可并獲得必要功能，而大型企業也會在購買許可之后獲得物有所值的體驗。
集成— 在這一領域處于領先地位并快速增長，意味著其他第三方工具也會優先選擇 Jira 構建本機集成，從而進一步增加 Jira 的價值。我們可以從現成列表中挑選需要的集成工具選項，整個過程一氣呵成、完全無需任何特別定制。
與競爭對手的比較
Trello— 作為一款免費使用的看板工具，Trello 同樣迅速積累起可觀的人氣。但隨著業務規模的擴展，需要跟蹤的問題也由數十個增長至數千個，這時 Trello 難以導航、搜索與報告的短板就開始暴露出來。
Pivotal Tracker— 在初創企業工作期間，我其實非常喜歡這款工具。但它更多關注產品管理，而非技術任務。相比之下，Jira 的產品管理功能也比較難上手，但至少可用而且足以替代其他獨立的產品管理工具。
2020 年頭號CHatOps 工具：MatterMost
這可能是這份榜單中最讓我驚喜的上榜成員，MatterMost 繼承了以往優秀工具的特性，同時引入本地部署支持以擴大自身普及范圍。對于企業而言，這一點非常重要，因為它不僅能夠控制數據、還可以幫助用戶與本地工具相集成——換言之，我們不必為了引入新功能而被迫跨出防火墻。
主要優勢
開源— MatterMost 的開源版本非常適合小型或者大型團隊。與 Slack 免費版會丟失歷史記錄的情況不同，MatterMost 允許用戶運行自有服務器，因此所有數據也都將保存在本地位置。
集成— MatterMost 的 API 幾乎 100% 基于 Slack API，因此 Slack 生態中的幾乎所有集成都能夠無縫對接 MatterMost。
與競爭對手的比較
Slack— Slack 很棒，但項目的體量已經過于龐大，需要認真考慮盈利問題。可以預見，Slack 將很快推出全面付費政策，并在免費版本當中閹割掉大量極具價值的功能——最重要的當然是保存聊天記錄功能。
Microsoft Teams— 大家可以嘗試把微軟產品與非微軟本地產品集成一下——祝各位好運！我要說的就這么多。
2020 年頭號文檔工具：Confluence
無論使用哪種工具，我們都很難創建并維護高質量的技術文檔。盡管最近市面上出現了不少 SaaS 文檔工具，但我還是很難接受把關于關鍵應用程序核心技術的敏感文檔存儲在第三方平臺當中。沒錯，我還是想把數據和文檔保存在本地，而 Conluence 正好解決了我的這個痛點。
主要優勢
易于管理—大多數自托管工具在啟動與運行階段都具有一定的復雜性，而且在規模化維護場景下會對專業技能提出要求。Conluence 服務器在這方面表現不錯，能夠以開箱即用的方式支持 10 到 10000 名用戶。
插件— Confluence 默認創建出的美觀、易于瀏覽、可導航文檔已經足以令人滿意，而豐富多彩的插件選項更是將 Wiki 的潛力發揮到了極致。
與競爭對手的比較
Read the docs— 很棒的開源項目，但我完全不會考慮在這里存儲與關鍵應用程序相關的敏感信息。
MarkDown— 這款工具特別適合記錄與代碼相關的內容，但我們很難將架構、過程或者其他類型的文檔直接保存為 MarkDown 格式。
Jekyll— 在記錄技術信息時，我并不想簡單構建一個靜態站點并在每次更新時調整其中的內容。Confluence 提供簡單易用的版本管理系統，極大降低了內部文檔的管理難度。
小程序開發6. 2020 年最佳 DevOps 工具總結
時至今日，市場上提供多達數百種 DevOps 工具，剛剛接觸的朋友可能難以弄清它們到底是干嘛用的、在特定場景下具體該如何選擇。希望今天這份簡單的指南，能夠幫助大家明確自己的 DevOps 工具堆棧需求，并快速建立起完整的 CI/CD 管道。最后讓我們以一句共勉作結：能自動化，就自動化！
以上文章由北京艾銻無限科技發展有限公司整理
相關文章
IT電腦維護外包
關閉