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

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

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

什么是 DevOps？

DevOps 是一種軟件開發方法，旨在彌合開發和運營團隊之間的差距。它強調這兩個團隊之間的協作和溝通，以確保高質量軟件產品的無縫交付。

其背后的核心原則是：

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

平臺工程

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

平臺工程是一門專注于構建和維護支持軟件開發過程所需的基礎設施和工具的學科。這包括底層硬件、軟件和網絡基礎設施，以及開發和運營團隊使用的工具和平臺。

換句話說，DevOps 關注改進軟件的開發和交付方式，而平臺工程關注構建和維護支持該過程的平臺和工具。

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

我們從哪里開始？

在學習 DevOps 時，重要的是要對該領域常用的工具和技術有深入的了解。以下是一些需要學習的最重要的工具和技術：

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

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

請記住，您需要學習的具體工具和技術取決于您的組織和您正在從事的項目的需求。但是，通過深入了解 DevOps 中最常用的工具和技術，您將為應對各種項目和挑戰做好充分準備。

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

版本控制

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

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

分支保護

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

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

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

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

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

處理拉取請求

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

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

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

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

最后

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

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