三十年后，我仍然热爱成为一名软件工程师。事实上，我最近读了威尔·拉森（Will Larson）的《员工工程师：超越管理轨道的领导力》，这进一步点燃了我以编程方式解决复杂问题的热情。知道雇主继续照顾员工、原则和杰出的工作分类，为想要成为一名工程师的技术人员提供了新鲜空气。
不幸的是，好的事情有时也会带来不太好的事情。对于今天的软件工程师来说，现实并不那么理想，因为 Toil 不断寻找一种方法来破坏日常工作效率。一个常见的例子是部署我们的工件——尤其是部署到生产环境中。
是时候更加重视部署自动化了。
传统的部署生命周期
软件工程师的开发生命周期通常围绕三个简单的步骤：开发、审查和合并。基于这些步骤，以下流程图说明了传统的部署生命周期：
图 1.传统开发生命周期
在图 1 中，软件工程师介绍了底层源代码的更新。创建合并请求后，持续集成 (CI) 工具将执行单元测试并执行静态代码分析。如果成功完成这些步骤，第二位软件工程师将对更改进行代码审查。如果这些更改获得批准，原始软件工程师会将源代码更改合并到主分支中。
此时，软件工程师开始部署到开发环境 (DEV)，该部署由持续交付 (CD) 工具处理。在此示例中，候选版本被部署到开发人员并执行其他测试（如回归测试）。如果这两个步骤都通过，软件工程师将通过相同的 CD 工具启动到 QA 环境的部署。接下来，软件工程师创建变更单以将源代码更新发布到生产环境 (Prod) 中。一旦批准经理批准了变更单，软件工程师就会开始部署到产品中。此步骤指示 CD 工具执行产品部署。
不幸的是，流程中有几个点涉及到基于人工的任务。
是时候专注于消除辛劳了
Google 站点可靠性工程的 Eric Harvieux对 Toil 的定义如下：
“辛劳是一种往往是手动的、重复性的、自动化的、战术性的工作，缺乏持久的价值，并且随着服务的增长而线性扩展。”
软件工程师应该改变他们的心态，认识到在他们的角色和职责中识别辛苦。一旦承认辛劳，就应该制定任务来消除这些不利于生产力的项目。大多数敏捷团队会预留 20% 的冲刺能力用于积压任务。消除劳累始终是此类工作的完美候选者。
在图 1 中，以下任务是手动处理的，应视为“Toil”：
- 开始DEV部署
- 开始质量检查部署
- 创建变更单
- 经理批准变更票
- 开始产品部署
为了推动下一代部署生命周期，实现“Toil-free”非常重要。
DevOps 生命周期和部署自动化
虽然消除繁重工作是下一代部署生命周期的一个重要方面，但通过 DevOps 实现部署自动化也同样重要。使用 DevOps 管道，我们可以自动化部署流程，如下所示：
- 合并到主事件完成后创建发布候选映像。
- 创建新的候选版本时，自动部署到 DEV。
- 成功部署到 DEV 后继续部署到 QA。
- 一旦 QA 部署成功，就以编程方式创建变更票证。
在实施上述自动化过程中，消除了五项人工任务中的三项。为了减轻剩下的两项任务，可以利用可观察性平台。
服务所有者通常依赖其可观察性平台来支持和维护在生产中运行的应用程序。通过扩展覆盖范围以包括较低的环境（例如 DEV 和 QA），DevOps 管道可以使用Ansible等开源工具与部署生命周期期间发出的指标进行交互。
这意味着，当 DevOps 管道对环境进行更改时，可以创建Ansible Playbook来监视给定的一组指标，以便了解部署是否按预期运行。如果没有出现异常或错误，管道将继续运行。否则，当前任务将中止并恢复部署的先前状态。
因此，使用服务所有者和可观察性平台定义的指标集合，经理批准的需要就会减少。这是因为合并请求的批准是分析更改的地方。此外，通常会添加批准经理步骤，因为不存在更好的替代方案。更换经理审批步骤后，可以通过相同的 DevOps 管道触发到 Prod 的部署。
采用这种方法，变更单的状态可以反映自动化完成任务时的实际状态。示例雕像包括Created、To Be Reviewed、Approved、Started、In Progress和Completed（或Completed With Errors）。
下一代部署生命周期
通过消除 Toil 并通过管道引入 DevOps 自动化，可以创建下一代部署生命周期。
图 2. 下一代部署生命周期
在图 2 中，部署生命周期变得更小，不再需要审批经理角色。相反，可观测平台用于监控 DevOps 管道。
在下一代部署生命周期中，软件工程师在合并请求获得批准后执行合并到主步骤。从此时起，该过程的其余部分将完全自动化。如果在 CD 管道步骤期间发生任何错误，管道将停止并恢复之前的状态。
与图 1 相比，所有现有的 Toil 都已完全消除，团队可以认为合并到主事件是下一个生产版本的入口点。更令人兴奋的是，团队在采用此策略时将看到其承诺部署比率的改善。
粉碎不合理的阻拦者
在考虑下一代部署生命周期时，经常会出现三个常见的想法：
1. 在部署之前我们需要让企业知道
软件工程师应努力以不需要业务级批准的方式增强或更新服务。使用功能标志和版本化 URI 是如何在不影响现有客户的情况下实现自动化发布的示例。然而，传达计划的功能和修复以及预期的时间范围始终是一个好主意。
2. 经理应该知道将要部署什么
虽然这是一个公平的说法，但批准经理对更新的了解应该在冲刺计划阶段（或类似阶段）建立。一旦给定的一组工作开始，期望该工作将在给定的开发迭代期间完成并部署。像软件工程师一样，管理人员应该采用合并到主线最终导致部署到生产的思维方式。
3. 在将变更投入生产之前，至少应该有一个人批准变更
这是一个有效的语句，它实际上发生在合并请求阶段。事实上，下一代部署生命周期中剩余的批准是有充分理由的。当一名或多名审批者审查合并请求时，他们处于最佳位置（在最佳时间点）来审查和质疑正在完成的工作。此后，可观察性平台监控 DevOps 管道是否出现任何意外问题就更有意义。
结论
传统的开发生命周期通常包括人工审批和大量不可接受的工作。随着时间的推移，这种辛苦不仅会成为挫败感的根源，还会影响软件工程师的生产力和心理健康。团队应优先考虑消除其角色和职责中的辛苦工作，并使用 DevOps 管道并与现有可观察性平台集成来推动下一代开发生命周期。采用这种方法将使团队能够采用“合并到主线等于部署到产品”的心态。这样做的一个好处是，提交部署率将会提高。
三十年前，我发现了作为一名软件工程师的热情，三十年后，我仍然热爱成为一名软件工程师。事实上，我对未来的道路更加兴奋，由于 DevOps 自动化和劳力消除，不再需要人工审批。
