软件架构指标

第 5 章. 私有构建和度量：DevOps 过渡期的生存工具

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

克里斯蒂安-西塞里

很多人认为软件架构 是一门手艺，但我认为它更像是一门科学。科学家倾向于测量事物，作为进一步推理的基础。即使无法获得精确的数字，软件架构的数学方法也依赖于可测量的数量，如度量和指标。有时，这种方法取决于在特定情况下哪些度量是合理的，哪些是不合理的。如何确保您的关键绩效指标能为您的组织提供决策所需的信息，帮助其做出如何投入时间和精力的决策？

要实现出色的指标，需要一个完善的系统和大量的工作。但事实是，您可能还没有一个完善的系统，或者您的组织还没有投入足够的精力，以 DevOps 最佳实践为基础实现出色的指标。DevOps 是一种文化转变；人们很容易对这一概念产生误解，而且公司并不总是致力于全面采用最佳实践。即使这是目标，学习和实施最佳实践也是一个需要时间的过程。现实并不总是最好的情况，标准指标并不总能反映真实问题。

那么，当你想实施最佳实践，但你的组织还没有做到这一点时，你能做些什么呢？在这种不太理想的情况下，我认为拥有一套能够帮助你 "度过 "过渡期并保持高效的实践和衡量标准仍然是非常有用和重要的。这就是本章的主题。

我将向你展示一些在真实情况下开展的真实项目案例--并说明使用私有构建和度量标准来帮助你完成项目的理由。您将看到当您遇到以下问题时，度量和私有构建如何帮您解决：

• DevOps 团队与质量保证团队脱节

• 非生产性反馈回路

• 过度依赖自动化而缺乏真正的理解

• 失去对验证和自动化的主人翁意识

作为一名顾问，我看到了这些和其他一些 "反模式"。它们并不理想，但肯定也不罕见。本章介绍的衡量标准可以帮助处于类似情况下的团队确定需求的优先级，并绘制出改善开发流程的路线图，而不至于太痛苦。

关键术语

Agile 运动，尤其是 eXtreme 编程（XP）的兴起，将开发界的焦点转向了 自动化。马丁-福勒（Martin Fowler）在 2011 年清楚地解释了自动化背后的理念、¹其背后的理念是，"伤筋动骨"（即花费大量时间或精力）的活动应尽可能频繁地进行，以便获得更多反馈和实践，并将工作分解成更小的块。这类活动应被视为自动化的候选对象。²

CI/CD

此外，Fowler 还在 2006 年的 中支持持续集成（CI），并将其定义为一种开发实践："持续集成是一种软件开发实践，团队成员经常集成他们的工作。[通常情况下，每个人至少每天集成一次，每天集成多次。每次集成都会通过自动构建（包括测试）进行验证，以尽快发现集成错误"。³

Fowler 接着将 CI 方法论作为一套实践来讨论，其中之一就是自动化。自动化还支持日常开发活动。正如我将在本章后面讨论的那样，这里的关键点在于避免破坏这种共享的构建/代码线。

持续集成的概念已扩展到包括持续交付（CD），通常一起称为 CI/CD。⁴CI 只是流程的第一部分，通常只涉及开发团队。软件交付是一个复杂的过程，涉及利益相关者和其他技术团队（如运营和质量保证）。CD 将他们都集中到了自动化的轨道上。即便如此，自动化也只能为流程提供支持。

在这里，我们必须清楚 CI/CD 是如何工作的，这样你才能跟上案例研究的步伐，所以请允许我更详细地介绍一下。由于现代软件通常被划分为多个组件，因此交付管道的后期阶段通常需要运行复杂的交互测试，以验证没有任何问题。这些验证要么是自动运行，要么是手动运行。在这两种情况下，发现缺陷的时间越晚，修复缺陷的成本就可能越高。边缘情况是最终用户在生产中报告缺陷。当这种情况发生时，支持团队就会参与进来：必须报告缺陷，可能还要对缺陷进行分类，并根据问题的紧迫性制定修复计划。 ...