我以一個(gè)笑話開始我的一些談話：在我那個(gè)時(shí)代，我們沒(méi)有監(jiān)控或可觀察性。我們會(huì)去服務(wù)器試一試。聽到高清旋轉(zhuǎn)？它的工作！

我們沒(méi)有 DevOps。如果幸運(yùn)的話，我們有一些管理員和技術(shù)人員來(lái)解決硬件問(wèn)題。就是這樣。在一家小公司，我們會(huì)自己做所有這些。今天這不再實(shí)用。部署和規(guī)模的復(fù)雜性如此之大，很難想象一家成長(zhǎng)中的公司沒(méi)有專門負(fù)責(zé)運(yùn)營(yíng)的工程師。

在本系列中，我希望向您介紹 DevOps 使用的一些核心原則和工具。這是我們?cè)诳赡芨緵](méi)有 DevOps 角色的初創(chuàng)公司中需要掌握的一項(xiàng)重要技能。或者在一家大公司，我們需要與 DevOps 團(tuán)隊(duì)溝通并解釋我們的需求或要求。

什么是 DevOps？

DevOps 是一種軟件開發(fā)方法，旨在彌合開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)之間的差距。它強(qiáng)調(diào)這兩個(gè)團(tuán)隊(duì)之間的協(xié)作和溝通，以確保高質(zhì)量軟件產(chǎn)品的無(wú)縫交付。

其背后的核心原則是：

1. 持續(xù)集成和持續(xù)交付 (CI/CD) — CI/CD 是 DevOps 的關(guān)鍵原則之一。它涉及用于構(gòu)建、測(cè)試和部署軟件的自動(dòng)化過(guò)程。借助 CI/CD，開發(fā)人員可以在開發(fā)周期的早期發(fā)現(xiàn)并修復(fù)錯(cuò)誤，從而更快、更可靠地交付軟件。
   作為開發(fā)人員，CI/CD 可以通過(guò)為您提供更快的反饋循環(huán)來(lái)幫助您，使您能夠更改代碼并實(shí)時(shí)查看結(jié)果。這有助于您快速識(shí)別和修復(fù)任何問(wèn)題，從而節(jié)省時(shí)間并確保您的代碼始終處于可發(fā)布狀態(tài)。
   請(qǐng)注意，CD 代表持續(xù)交付和部署。這是一個(gè)非常令人沮喪的首字母縮寫詞。不過(guò)，兩者之間的區(qū)別很簡(jiǎn)單。部署依賴于交付。除非構(gòu)建并交付，否則我們無(wú)法部署應(yīng)用程序。部署方面意味著將我們的提交合并到主分支中將導(dǎo)致在某個(gè)時(shí)候?qū)ιa(chǎn)進(jìn)行更改而無(wú)需任何用戶參與。
2. 自動(dòng)化——自動(dòng)化涉及自動(dòng)化重復(fù)性任務(wù)，例如構(gòu)建、測(cè)試和部署軟件。這有助于減少執(zhí)行這些任務(wù)所需的時(shí)間和精力，讓開發(fā)人員有更多時(shí)間專注于更重要的任務(wù)。
   作為開發(fā)人員，自動(dòng)化可以幫助您騰出時(shí)間，讓您專注于編寫代碼，而不是將時(shí)間花在手動(dòng)任務(wù)上。此外，自動(dòng)化有助于降低人為錯(cuò)誤的風(fēng)險(xiǎn)，確保您的代碼始終得到正確部署。
3. 協(xié)作和溝通——DevOps強(qiáng)調(diào)開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)之間的協(xié)作和溝通。這有助于確保每個(gè)人都在同一頁(yè)面上并朝著共同的目標(biāo)努力。它還有助于減少解決任何可能出現(xiàn)的問(wèn)題所需的時(shí)間和精力。

平臺(tái)工程

最近，平臺(tái)工程領(lǐng)域有所興起。這有點(diǎn)令人困惑，因?yàn)?DevOps 和平臺(tái)工程師的角色之間的重疊不一定很清楚。然而，它們是軟件開發(fā)中兩個(gè)相關(guān)但截然不同的領(lǐng)域。雖然兩者都關(guān)注改進(jìn)軟件交付和操作流程，但它們有不同的側(cè)重點(diǎn)和方法。

平臺(tái)工程是一門專注于構(gòu)建和維護(hù)支持軟件開發(fā)過(guò)程所需的基礎(chǔ)設(shè)施和工具的學(xué)科。這包括底層硬件、軟件和網(wǎng)絡(luò)基礎(chǔ)設(shè)施，以及開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)使用的工具和平臺(tái)。

換句話說(shuō)，DevOps 關(guān)注改進(jìn)軟件的開發(fā)和交付方式，而平臺(tái)工程關(guān)注構(gòu)建和維護(hù)支持該過(guò)程的平臺(tái)和工具。

雖然 DevOps 和平臺(tái)工程相輔相成，但它們服務(wù)于不同的目的。DevOps 幫助團(tuán)隊(duì)更有效地協(xié)作并更快地交付軟件，而平臺(tái)工程提供支持該過(guò)程所需的基礎(chǔ)設(shè)施和工具。

我們從哪里開始？

在學(xué)習(xí) DevOps 時(shí)，重要的是要對(duì)該領(lǐng)域常用的工具和技術(shù)有深入的了解。以下是一些需要學(xué)習(xí)的最重要的工具和技術(shù)：

1. 版本控制系統(tǒng)：了解如何使用版本控制系統(tǒng)（例如 Git）是 DevOps 的關(guān)鍵組成部分。版本控制系統(tǒng)允許團(tuán)隊(duì)跟蹤對(duì)其代碼的更改，在項(xiàng)目上進(jìn)行協(xié)作，并在必要時(shí)回滾更改。我假設(shè)您了解 Git 并且將跳過(guò)它并直接進(jìn)入下一階段。
2. 持續(xù)集成 (CI) 和持續(xù)部署 (CD) 工具： CI/CD 工具是 DevOps 的核心，用于自動(dòng)化代碼的構(gòu)建、測(cè)試和部署。流行的 CI/CD 工具包括 Jenkins、Travis CI、CircleCI 和 GitLab CI/CD。我將專注于 GitHub Actions。它在 DevOps 領(lǐng)域并不是一個(gè)流行的工具，因?yàn)樗鄬?duì)有限，但對(duì)于我們作為開發(fā)人員的需求來(lái)說(shuō)，它非常棒。
3. 基礎(chǔ)架構(gòu)即代碼 (IaC) 工具： IaC 工具讓我們可以像管理源代碼一樣管理我們的基礎(chǔ)架構(gòu)。這使得基礎(chǔ)設(shè)施的供應(yīng)、配置和部署自動(dòng)化變得更加容易。流行的 IaC 工具包括 Terraform、CloudFormation 和 Ansible。我也喜歡 Pulumi，它允許您使用常規(guī)編程語(yǔ)言來(lái)描述基礎(chǔ)設(shè)施，包括 Java。
4. 容器化： Docker 等容器化技術(shù)允許您以一致且可移植的方式打包和部署應(yīng)用程序，從而更輕松地在開發(fā)、測(cè)試和生產(chǎn)環(huán)境之間移動(dòng)應(yīng)用程序。
5. 編排：編排是指多個(gè)任務(wù)和流程的自動(dòng)協(xié)調(diào)和管理，通?？缍鄠€(gè)系統(tǒng)和技術(shù)。在 DevOps 中，編排用于自動(dòng)部署和管理復(fù)雜的多層應(yīng)用程序和基礎(chǔ)架構(gòu)。
   流行的編排工具包括 Kubernetes、Docker Swarm 和 Apache Mesos。這些工具允許團(tuán)隊(duì)管理和部署容器，自動(dòng)擴(kuò)展應(yīng)用程序，并管理系統(tǒng)的整體健康狀況和可用性。
6. 監(jiān)控和日志記錄工具：監(jiān)控和日志記錄工具允許您跟蹤系統(tǒng)和應(yīng)用程序的性能和行為。流行的監(jiān)控工具包括 Nagios、Zabbix 和 New Relic。Prometheus 和 Grafana 大概是近幾年這個(gè)領(lǐng)域最火的。流行的日志記錄工具包括 ELK Stack（Elasticsearch、Logstash 和 Kibana）、Graylog 和 Fluentd。
7. 配置管理工具：配置管理工具，例如 Puppet、Chef 和 Ansible，可讓您自動(dòng)配置和管理您的服務(wù)器和應(yīng)用程序。
8. 云計(jì)算平臺(tái)：云計(jì)算平臺(tái)，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform (GCP)。它們提供 DevOps 實(shí)踐所需的基礎(chǔ)設(shè)施和服務(wù)。

除了這些工具之外，了解 DevOps 實(shí)踐和方法（例如敏捷）也很重要。

請(qǐng)記住，您需要學(xué)習(xí)的具體工具和技術(shù)取決于您的組織和您正在從事的項(xiàng)目的需求。但是，通過(guò)深入了解 DevOps 中最常用的工具和技術(shù)，您將為應(yīng)對(duì)各種項(xiàng)目和挑戰(zhàn)做好充分準(zhǔn)備。

大多數(shù)特性和功能都是可轉(zhuǎn)移的。如果您在一種工具中學(xué)習(xí)了 CI 原則，那么轉(zhuǎn)移到另一種工具將不會(huì)是無(wú)縫的。但這會(huì)相對(duì)容易。

版本控制

我們都使用 Git，至少我希望如此。Git 在版本控制方面的主導(dǎo)地位使得構(gòu)建深度集成的解決方案變得更加容易。作為開發(fā)人員，Git 主要被視為一個(gè)版本控制系統(tǒng)，可幫助我們管理和跟蹤代碼庫(kù)的更改。我們使用 Git 與其他開發(fā)人員協(xié)作、創(chuàng)建和管理分支、合并代碼更改以及跟蹤問(wèn)題和錯(cuò)誤。Git 是開發(fā)人員必不可少的工具，因?yàn)樗顾麄兡軌蚋咝矣行У靥幚泶a項(xiàng)目。

DevOps 有不同的優(yōu)勢(shì)。Git 被視為 CI/CD 管道的重要組成部分。在此上下文中，Git 用作存儲(chǔ)代碼和其他工件（如配置文件、腳本和構(gòu)建文件）的存儲(chǔ)庫(kù)。DevOps 專業(yè)人員使用 Git 來(lái)管理發(fā)布管道、自動(dòng)化構(gòu)建和管理部署配置。Git 是 DevOps 工具鏈的重要組成部分，因?yàn)樗试S將代碼更改無(wú)縫集成到 CI/CD 管道中，確保及時(shí)將軟件交付到生產(chǎn)環(huán)境。

分支保護(hù)

默認(rèn)情況下，GitHub 項(xiàng)目允許任何人向主（master）分支提交更改。這在大多數(shù)項(xiàng)目中都是有問(wèn)題的。我們通常希望阻止對(duì)該分支的提交，以便我們可以控制主線的質(zhì)量。在使用 CI 時(shí)尤其如此，因?yàn)?master 的中斷可能會(huì)停止其他開發(fā)人員的工作。

我們可以通過(guò)強(qiáng)制每個(gè)人在分支上工作并向 master 提交拉取請(qǐng)求來(lái)最小化這種風(fēng)險(xiǎn)。這可以通過(guò)需要一名或多名審閱者的代碼審閱規(guī)則進(jìn)一步采取。GitHub 具有高度可配置的規(guī)則，可以在項(xiàng)目設(shè)置中啟用。正如你在這里看到的。

在 GitHub 的 master 分支上啟用分支保護(hù)有幾個(gè)好處，包括：

• 防止對(duì) master 分支的意外更改：通過(guò)在 master 分支上啟用分支保護(hù)，可以防止貢獻(xiàn)者意外地將更改推送到分支。這有助于確保主分支始終包含穩(wěn)定且經(jīng)過(guò)測(cè)試的代碼。
• 強(qiáng)制代碼審查：您可以要求對(duì) master 分支的所有更改在合并之前由一個(gè)或多個(gè)人審查。這有助于確保對(duì) master 分支的更改是高質(zhì)量的并符合您團(tuán)隊(duì)的標(biāo)準(zhǔn)。
• 防止強(qiáng)制推送：在 master 分支上啟用分支保護(hù)可以防止貢獻(xiàn)者將更改強(qiáng)制推送到分支，這可能會(huì)覆蓋其他人所做的更改。這有助于確保對(duì) master 分支的更改是有意且經(jīng)過(guò)仔細(xì)考慮的。
• 強(qiáng)制執(zhí)行狀態(tài)檢查：您可以要求在合并對(duì) master 分支的更改之前滿足某些條件，例如通過(guò)測(cè)試或成功構(gòu)建。這有助于確保對(duì) master 分支的更改是高質(zhì)量的，并且不會(huì)引入新的錯(cuò)誤或問(wèn)題。

總的來(lái)說(shuō)，在 GitHub 的 master 分支上啟用分支保護(hù)有助于確保對(duì)代碼庫(kù)的更改得到仔細(xì)審查、測(cè)試和高質(zhì)量。這有助于提高軟件的穩(wěn)定性和可靠性。

處理拉取請(qǐng)求

作為開發(fā)人員，我們發(fā)現(xiàn)使用分支和拉取請(qǐng)求允許我們收集多個(gè)單獨(dú)的提交和對(duì)單個(gè)功能的更改。這是我們作為開發(fā)人員的角色與 DevOps 的角色之間最先重疊的領(lǐng)域之一。拉取請(qǐng)求讓我們?cè)趯⒋a合并到主分支之前協(xié)作并審查彼此的代碼。這有助于識(shí)別問(wèn)題并確保代碼庫(kù)保持穩(wěn)定和一致。通過(guò)拉取請(qǐng)求，團(tuán)隊(duì)可以討論和審查代碼更改，提出改進(jìn)建議，并在錯(cuò)誤投入生產(chǎn)之前發(fā)現(xiàn)錯(cuò)誤。這對(duì)于保持代碼質(zhì)量、減少技術(shù)債務(wù)和確保代碼庫(kù)的可維護(hù)性至關(guān)重要。DevOps 的作用是調(diào)整質(zhì)量與流失。

拉取請(qǐng)求應(yīng)該有多少審閱者？是否需要特定的審稿人？我們需要測(cè)試覆蓋率水平嗎？

DevOps 需要調(diào)整開發(fā)人員生產(chǎn)力、穩(wěn)定性和流失率之間的比例。通過(guò)增加審閱者數(shù)量或強(qiáng)制由特定工程師進(jìn)行審閱，我們會(huì)造成瓶頸并減緩開發(fā)速度。另一方面是質(zhì)量的潛在提高。我們根據(jù)經(jīng)驗(yàn)法則和最佳實(shí)踐來(lái)決定這些指標(biāo)。但是一個(gè)好的 DevOps 工程師會(huì)通過(guò)有助于在未來(lái)做出明智決策的指標(biāo)來(lái)完成所有事情。例如，如果我們強(qiáng)制要求兩名審閱者，那么我們可以查看合并拉取請(qǐng)求所需的時(shí)間，這可能會(huì)增加。但我們可以將其與政策出臺(tái)后的倒退和問(wèn)題數(shù)量進(jìn)行比較。這樣，我們就可以清楚地了解政策的成本和收益。

拉取請(qǐng)求的第二個(gè)好處是它們?cè)?CI/CD 過(guò)程中的關(guān)鍵作用。當(dāng)開發(fā)人員創(chuàng)建拉取請(qǐng)求時(shí)，它會(huì)觸發(fā)自動(dòng)構(gòu)建和測(cè)試過(guò)程，該過(guò)程會(huì)驗(yàn)證代碼更改是否與代碼庫(kù)的其余部分兼容，并且所有測(cè)試是否通過(guò)。這有助于在開發(fā)過(guò)程的早期發(fā)現(xiàn)任何問(wèn)題，并防止錯(cuò)誤進(jìn)入生產(chǎn)環(huán)境。一旦構(gòu)建和測(cè)試過(guò)程成功，拉取請(qǐng)求就可以合并到主分支中，觸發(fā)發(fā)布管道將更改部署到生產(chǎn)環(huán)境中。我將在本系列的下一部分中更深入地介紹 CI。

最后

我覺(jué)得 DevOps 的討論往往很模糊。DevOps 工程師的角色和開發(fā)人員的角色之間沒(méi)有硬性界限，因?yàn)樗麄兪情_發(fā)人員并且是研發(fā)團(tuán)隊(duì)的一部分。DevOps 跨越了管理和開發(fā)之間的那條細(xì)線。他們需要滿足兩端有時(shí)相互沖突的要求。我認(rèn)為了解他們的工作和工具可以幫助我們成為更好的開發(fā)人員、更好的隊(duì)友和更好的管理者。

下次我們將討論使用 GitHub 操作構(gòu)建 CI 管道。處理您的工件。管理秘密并控制一切。請(qǐng)注意，我們不會(huì)在這個(gè)階段詳細(xì)討論持續(xù)交付，因?yàn)檫@會(huì)把我們拖到部署的討論中。一旦我們涵蓋了 IaC、Kubernetes、Docker 等部署技術(shù)，我完全打算回到它并討論 CD。