软件工程师也需要了解 DevOps，从 CI/CD 开始

DevOps 现在很火。似乎每个软件工程职位，无论职位名称是什么，都要求具备 DevOps 经验和专业知识。

当一家科技公司将其单体应用拆分成微服务时，其每个工程团队现在都从头到尾负责各自负责的部分。软件工程师不再只是构建应用程序，他们还负责代码库的维护、持续集成的设置、构建流水线的配置以及应用程序的部署。

在这个跨职能团队和微服务架构的世界中，DevOps 技能变得越来越重要，而这始于理解 CI/CD（持续集成、持续交付和持续部署）。

在本文中，我们将讨论 CI/CD 的最佳实践以及Armory等平台如何帮助管理所涉及的一些复杂性。

持续集成（CI）

持续集成 (CI)是“将来自多个贡献者的代码更改自动集成到单个软件项目中的实践”。

由于每天都有多名开发人员将代码合并到主分支，因此实施自动化检查以确保代码始终处于良好的工作状态至关重要。这意味着在合并新代码之前，应该运行代码格式化程序、代码 linter 和单元测试。CI 流水线无需依赖开发人员记住在本地使用这些工具，而是帮助自动运行每个所需作业，从而防止不良代码合并到主分支。

良好的持续集成 (CI) 流水线应该速度快。这意味着尽可能并行运行流水线作业，并拥有快速的测试套件。

良好的持续集成 (CI) 管道也应该可靠。如果构建出现问题，工程师应立即修复，因为构建失败会阻止所有未完成的合并请求合并。如果测试存在问题，应暂时禁用并尽快修复。

应用应该在持续集成 (CI) 流水线的起始阶段附近构建一次，即所有格式化程序、linter 和单元测试运行完毕之后。这样，构建的工件就可以在流水线的后续阶段随时使用。构建的工件随后可以部署在容器化环境中，并作为代码审阅者的审阅应用，以便在需要时快速验证更改。

成功为代码库设置 CI 流水线后，开发人员可以每天（甚至每天多次）向主分支提交代码。无需再忍受功能分支长时间运行、等待数月才能最终合并的痛苦！

遵循这些 CI 实践有助于始终保持主分支中的所有内容清洁且处于可部署状态，这就引出了 CI/CD 首字母缩略词的后半部分。

持续交付和持续部署（CD）

顺便提一下，我们来谈谈“持续交付”和“持续部署”之间的区别。持续交付是持续集成过程中生成构建工件的自然结果。此构建工件是应用程序的工作副本，可以部署到环境中。这意味着，您可以随时部署到生产环境！作为工程团队，您可以决定是每日部署、每周部署、每两周部署等等。在持续交付中，虽然您可以随时部署应用程序，但仍需要人工启动该流程来开始部署。

然而，持续部署比持续交付更进一步，因为合并到主分支的每个更改都会立即启动部署流程，无需任何人工干预。这非常令人兴奋，因为开发人员在合并代码几分钟后就能看到它们投入生产！（当然，前提是部署过程没有被任何失败的自动检查所阻碍，从而阻止新版本发布到生产环境中。）

无论您的组织选择持续交付还是持续部署，这两种实践的目的都是相同的：尽可能快速、频繁地为客户提供价值。告别季度发布！这就是敏捷的真谛。

持续交付中最重要的一点是，应用应该能够一键部署。换句话说，部署过程应该自动化。如果不遵循这一原则，部署过程中的多个复杂步骤必须由人工执行，部署过程就更容易出错。毕竟，我们是人，人都会犯错。

持续交付和持续部署的另一个关键原则是，您应该使用多级环境来运行应用。例如，您可能拥有开发环境、暂存环境和生产环境。在部署过程中，构建的工件可以从一个环境迁移到另一个环境。这些不同环境中的基础架构应尽可能相似，这样一旦应用投入生产，您就不会遇到重大意外。

部署策略

部署策略可能有所不同，但一些常用的技术是金丝雀部署、蓝绿部署和滚动蓝绿部署。

在金丝雀部署中，您首先会将应用的新版本发布给一小部分用户。当您确信这些更改对这些用户来说能够正常工作后，再将更改发布给其余用户。这是一种谨慎的代码发布方式，因为您最初不会一次性将更改应用到所有用户。

在蓝绿部署中，您将使用两个生产级环境。一个环境在生产环境中积极使用，包含应用程序的最新版本。第二个环境处于待机状态，没有流量路由到它。您将应用程序的新版本部署到待机环境，然后将所有流量路由到此环境，这使其成为新的生产环境。旧的生产环境将不再接收流量并成为待机环境。这使得部署新版本以及在需要时回滚版本变得非常容易，因为这两个过程都像重定向用户流量的去向一样简单。

当您的应用程序的多个实例都在同一环境中运行时，可以使用滚动蓝绿部署。例如，如果您在生产环境中使用了六个节点，请将第一个节点替换为运行新版应用程序的另一个节点。这样，现在您有五个节点运行旧版应用程序，一个节点运行新版应用程序。然后，您再次执行此操作，使比例变为四个旧节点和两个新节点。再替换四个节点后，现在所有六个节点都运行新版应用程序。

滚动部署既有优点也有缺点。由于无需一次性部署所有内容，因此风险较小；但由于每次只部署一个节点，因此完成完整发布也需要更多时间。

工具如何帮助 CI/CD

现在我们了解了 CI/CD 的最佳实践，那么可以使用哪些工具来帮助我们呢？对于 CI，有很多优秀的开源选项，例如Travis CI或CircleCI 。您甚至可以使用 GitHub（通过GitHub Actions）或 GitLab（通过GitLab CI ）的内置功能。这些工具大多数专注于 CI/CD 的 CI 部分，但也包含一些 CD 功能。使用这些 CI 工具，您可以创建管道，负责在每个新的合并请求上运行 linters 和测试。

说到持续交付 (CD)，Spinnaker是最流行的自动化部署开源工具之一。Spinnaker 最初由 Netflix 内部开发，之后才向更广泛的开发者社区发布。Spinnaker 的一大优势在于其灵活性，几乎支持所有云提供商，从 AWS 到 Azure，再到 GCP。Spinnaker 可以与您选择的持续交付 (CI) 工具集成，并使用您选择的部署策略部署您的应用。（我已经提到过它很灵活，对吧？）

使用 Spinnaker 进行金丝雀部署的示例管道可能看起来有点像这样：

在此工作流程中，我们看到构建工件已部署到初始金丝雀部署的小型服务器组集群中。在金丝雀部署中的功能变更经过手动审核和批准后，将通过部署新的生产集群并使用负载均衡器将流量引导至该新集群，从而完成蓝绿部署（Netflix 称之为红黑部署）。之后，金丝雀集群将被拆除，并且在所有人都确认新的生产集群运行良好后，旧的生产集群也将被销毁。

Armory平台将这一理念更进一步，提供企业级 Spinnaker 产品，以提高可视性、增强开发者能力和弹性。Armory 的仪表盘、日志记录和实时指标有助于开发者更好地了解其应用部署情况。由于许多复杂性被抽象到美观的 GUI 中，只需单击按钮即可执行部署和回滚。这使得即使是没有太多 DevOps 经验的开发者也能从头到尾掌控自己的应用。为了进一步增强您的信心，Armory 的策略引擎允许您配置防护栏，以确保每次部署都遵循公司的最佳实践和商定的规则。

结论

那么，我们学到了什么？首先，开发人员需要熟悉 CI/CD 最佳实践。其次，工程组织需要为开发人员提供合适的工具，以帮助提高生产力并减少错误。正如我们所见，用于 CD 的最佳工具之一是 Spinnaker，现在 Armory 对其进行了增强。通过共同实施这些 DevOps 原则，工程团队将对其代码更有信心，并能够更快地为客户交付价值。