本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

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

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

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

開發(fā)和構(gòu)建工具

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

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

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

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

 

 

 

圖源：unsplash

 

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

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

其優(yōu)點包括：

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

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

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

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

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

2. 數(shù)據(jù)管理工具：FlywayDB

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

由于存在兩個不同的系統(tǒng)，因此通過應用程序升級來協(xié)調(diào)數(shù)據(jù)庫更改也比較困難，而FlyWayDB解決了所有這些問題。

其主要優(yōu)勢在于：

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

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

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

自動化測試工具

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

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

1. 集成測試工具: Cucumber

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

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

其主要優(yōu)勢在于：

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

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

端對端測試工具

進行端到端測試時，有兩個重點領(lǐng)域需要關(guān)注：功能測試和負載測試。

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

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

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

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

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

其主要優(yōu)勢在于：

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

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

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

 

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

其主要優(yōu)勢在于：

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

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

部署工具

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

1. 構(gòu)件管理工具: Nexus

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

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

其主要優(yōu)勢在于：

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

2. 配置管理工具: Ansible

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

其主要優(yōu)勢在于：

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

其競爭對手有以下兩個：

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

3. 部署工具：Terraform

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

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

其主要優(yōu)勢在于：

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

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

開發(fā)運維工具運行

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

1. 工具即服務：AWS

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

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

其主要優(yōu)勢在于：

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

其競爭對手有以下幾個：

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

2. 編制工具:OpenShift

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

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

其主要優(yōu)勢在于：

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

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

3. 監(jiān)控工具: NewRelic

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

其主要優(yōu)勢在于：

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

其競爭對手有以下幾個：

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

4. 記錄工具: Splunk

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

其主要優(yōu)勢在于：

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

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

協(xié)作開發(fā)運維工具

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

1. 問題跟蹤工具：Jira

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

其主要優(yōu)勢在于：

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

其競爭對手有以下幾個：

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

2. 聊天運營工具:MatterMost

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

其主要優(yōu)勢在于：

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

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

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

3. 文檔工具:Confluence

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

其主要優(yōu)勢在于：

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

其競爭對手有以下幾個：

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

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

關(guān)鍵是要記住，將一切事物自動化!