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

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

在本系列中，我希望向您介紹 DevOps 使用的一些核心原則和工具。這是我們在可能根本沒有 DevOps 角色的初創(chuàng)公司中需要掌握的一項重要技能。或者在一家大公司，我們需要與 DevOps 團隊溝通并解釋我們的需求或要求。

什么是 DevOps？

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

其背后的核心原則是：

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

平臺工程

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

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

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

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

我們從哪里開始？

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

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

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

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

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

版本控制

我們都使用 Git，至少我希望如此。Git 在版本控制方面的主導(dǎo)地位使得構(gòu)建深度集成的解決方案變得更加容易。作為開發(fā)人員，Git 主要被視為一個版本控制系統(tǒng)，可幫助我們管理和跟蹤代碼庫的更改。我們使用 Git 與其他開發(fā)人員協(xié)作、創(chuàng)建和管理分支、合并代碼更改以及跟蹤問題和錯誤。Git 是開發(fā)人員必不可少的工具，因為它使他們能夠高效且有效地處理代碼項目。

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

分支保護

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

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

在 GitHub 的 master 分支上啟用分支保護有幾個好處，包括：

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

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

處理拉取請求

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

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

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

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

最后

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

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