Booking.com 利用 DORA 指标和微前端实现交付能力翻番

作者 | Rafal Gancarz

译者 | 平川

策划 | Tina

Booking.com 金融科技业务部门的团队对其平台的前后端进行了一系列改进，使交付能力提高了一倍（根据 DORA 指标）。此外，他们使用微前端（MFE）模式将单体 FE 应用程序分解为多个可单独部署的应用。

2022 年年中，Booking.com 新成立了一个工程团队，负责财务域的几个流程。该团队承继了一个比较大的平台架构的一部分，包括在 Vue 框架 下用 Perl 和 JavaScript 编写的单体前端应用程序，以及依赖于许多其他微服务的 Java 后端服务。

团队的所有权范围（图片来源：Booking.com 工程博客）

该团队很快就发现，对现有代码库进行修改并将其部署到生产环境中既危险又耗时。为了提高交付频率，团队决定采用定制的 DevOps 指标（由 DORA 提出）来跟踪交付过程的关键性能指标。为了建立基线，工程师开始记录交付速度指标（部署频率和变更前置时间）。此外，他们还选择了定制的可靠性 / 稳定性指标，包括服务可用性和开放缺陷数量，而不是 DORA 指标（变更故障率和平均恢复时间）。根据该团队的度量，在 2023 年 3 月至 11 月期间，交付速度这个关键指标提高了两倍，而质量和可用性保持稳定。

交付指标改进概览（图片来源：Booking.com 工程博客）

在整个观测期间，工程师们逐渐提高了 Java 后端服务的代码质量。他们还设法缩减了合并请求（又名 pull request）的大小，以减轻代码审查的痛苦，从而使这些请求成为团队成员优先考虑处理的对象。此外，开发人员还改进了部署过程，逐渐减少了手动验证步骤，并更多地依赖于经过改进的自动化测试。最后，他们切换到了全自动化部署，将部署时间从 40 分钟减少到了 4 分钟。

Booking.com 高级工程经理 Egor Savochkin 介绍了他们在此过程中降低变更时引入问题的风险以及改进代码的方法：

团队采用了童子军规则，在不中断特性开发工作的前提下，通过重构和自动化测试来提高代码质量。在实施变更或修复缺陷的同时，努力改进周边代码。并一定要是很大的改进。那可能很简单，比如在你接触到的类中添加单元测试，或者通过小范围的重构来消除代码异味。在团队选择将单体应用拆分为微前端（MFE）后，前端也有所改善，但并没能像希望的那样迅速实现。他们调整了代码评审流程，减少了对外部专家审批的依赖，代码评审时间降到了 8 分钟。通过快速代码审查，团队实现了更频繁但规模更小的部署，部署时间缩短到了 1 小时。

在此之前，InfoQ 还报道了 eBay 如何在重新设计 View Item 页面后显著提高了交付指标。

原文链接：

https://www.infoq.com/news/2024/02/booking-dora-micro-frontends/

声明：本文为 InfoQ 翻译，未经许可禁止转载。