面向开发人员的 DevOps — 简介和版本控制
我以一个笑话开始我的一些谈话：在我那个时代，我们没有监控或可观察性。我们会去服务器试一试。听到高清旋转？它的工作！
我们没有 DevOps。如果幸运的话，我们有一些管理员和技术人员来解决硬件问题。就是这样。在一家小公司，我们会自己做所有这些。今天这不再实用。部署和规模的复杂性如此之大，很难想象一家成长中的公司没有专门负责运营的工程师。
在本系列中，我希望向您介绍 DevOps 使用的一些核心原则和工具。这是我们在可能根本没有 DevOps 角色的初创公司中需要掌握的一项重要技能。或者在一家大公司，我们需要与 DevOps 团队沟通并解释我们的需求或要求。
什么是 DevOps？
DevOps 是一种软件开发方法，旨在弥合开发和运营团队之间的差距。它强调这两个团队之间的协作和沟通，以确保高质量软件产品的无缝交付。
其背后的核心原则是：
- 持续集成和持续交付 (CI/CD) — CI/CD 是 DevOps 的关键原则之一。它涉及用于构建、测试和部署软件的自动化过程。借助 CI/CD，开发人员可以在开发周期的早期发现并修复错误，从而更快、更可靠地交付软件。
作为开发人员，CI/CD 可以通过为您提供更快的反馈循环来帮助您，使您能够更改代码并实时查看结果。这有助于您快速识别和修复任何问题，从而节省时间并确保您的代码始终处于可发布状态。
请注意，CD 代表持续交付和部署。这是一个非常令人沮丧的首字母缩写词。不过，两者之间的区别很简单。部署依赖于交付。除非构建并交付，否则我们无法部署应用程序。部署方面意味着将我们的提交合并到主分支中将导致在某个时候对生产进行更改而无需任何用户参与。 - 自动化——自动化涉及自动化重复性任务，例如构建、测试和部署软件。这有助于减少执行这些任务所需的时间和精力，让开发人员有更多时间专注于更重要的任务。
作为开发人员，自动化可以帮助您腾出时间，让您专注于编写代码，而不是将时间花在手动任务上。此外，自动化有助于降低人为错误的风险，确保您的代码始终得到正确部署。 - 协作和沟通——DevOps强调开发和运营团队之间的协作和沟通。这有助于确保每个人都在同一页面上并朝着共同的目标努力。它还有助于减少解决任何可能出现的问题所需的时间和精力。
平台工程
最近，平台工程领域有所兴起。这有点令人困惑，因为 DevOps 和平台工程师的角色之间的重叠不一定很清楚。然而，它们是软件开发中两个相关但截然不同的领域。虽然两者都关注改进软件交付和操作流程，但它们有不同的侧重点和方法。
平台工程是一门专注于构建和维护支持软件开发过程所需的基础设施和工具的学科。这包括底层硬件、软件和网络基础设施，以及开发和运营团队使用的工具和平台。
换句话说，DevOps 关注改进软件的开发和交付方式，而平台工程关注构建和维护支持该过程的平台和工具。
虽然 DevOps 和平台工程相辅相成，但它们服务于不同的目的。DevOps 帮助团队更有效地协作并更快地交付软件，而平台工程提供支持该过程所需的基础设施和工具。
我们从哪里开始？
在学习 DevOps 时，重要的是要对该领域常用的工具和技术有深入的了解。以下是一些需要学习的最重要的工具和技术：
- 版本控制系统：了解如何使用版本控制系统（例如 Git）是 DevOps 的关键组成部分。版本控制系统允许团队跟踪对其代码的更改，在项目上进行协作，并在必要时回滚更改。我假设您了解 Git 并且将跳过它并直接进入下一阶段。
- 持续集成 (CI) 和持续部署 (CD) 工具： CI/CD 工具是 DevOps 的核心，用于自动化代码的构建、测试和部署。流行的 CI/CD 工具包括 Jenkins、Travis CI、CircleCI 和 GitLab CI/CD。我将专注于 Github Actions。它在 DevOps 领域并不是一个流行的工具，因为它相对有限，但对于我们作为开发人员的需求来说，它非常棒。
- 基础架构即代码 (IaC) 工具： IaC 工具让我们可以像管理源代码一样管理我们的基础架构。这使得基础设施的供应、配置和部署自动化变得更加容易。流行的 IaC 工具包括 Terraform、CloudFormation 和 Ansible。我也喜欢 Pulumi，它允许您使用常规编程语言来描述基础设施，包括 JAVA。
- 容器化： Docker 等容器化技术允许您以一致且可移植的方式打包和部署应用程序，从而更轻松地在开发、测试和生产环境之间移动应用程序。
- 编排：编排是指多个任务和流程的自动协调和管理，通常跨多个系统和技术。在 DevOps 中，编排用于自动部署和管理复杂的多层应用程序和基础架构。
流行的编排工具包括 Kube.NETes、Docker Swarm 和 Apache Mesos。这些工具允许团队管理和部署容器，自动扩展应用程序，并管理系统的整体健康状况和可用性。 - 监控和日志记录工具：监控和日志记录工具允许您跟踪系统和应用程序的性能和行为。流行的监控工具包括 NagIOS、Zabbix 和 New Relic。Prometheus 和 Grafana 大概是近几年这个领域最火的。流行的日志记录工具包括 ELK Stack（Elasticsearch、Logstash 和 Kibana）、Graylog 和 Fluentd。
- 配置管理工具：配置管理工具，例如 Puppet、Chef 和 Ansible，可让您自动配置和管理您的服务器和应用程序。
- 云计算平台：云计算平台，例如 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。
