Booking.com 金融技术业务部门的团队对其平台的后端和前端实施了一系列改进措施,并通过 DORA 指标将交付性能提高了一倍。此外,还使用了微前端 (MFE) 模式,将单体 FE 应用程序分解为多个可单独部署的分解应用程序。
2022 年年中,Booking.com 成立了一个新的工程团队,负责财务领域的多个流程。该团队选用了一部分更广泛的平台架构,包括一个使用 Perl 和 Javascript(使用 Vue Framework)编写的单体前端应用程序,以及一个依赖于许多其他微服务的 Java 后端服务。
团队很快发现,对现有代码库进行更改并将其部署到生产中既有风险又耗时。为了提高交付频率,团队决定采用 DORA 提出的定制 DevOps 指标来跟踪交付流程的关键绩效指标。工程师们开始记录交付速度指标(部署频率和变更准备时间),以建立基线。他们还选择了定制的可靠性/稳定性指标,包括服务可用性和开放缺陷数量,而不是 DORA 指标(变更失败率和平均恢复时间)。根据团队的测量,在 2023 年 3 月至 11 月期间,关键的交付速度指标提高了两倍,而质量和可用性则保持稳定。
在整个观察期间,工程师们逐渐提高了 Java 后端服务的代码质量。他们还转向了更小的合并请求(又称为 pull requests),以确保代码审查不那么痛苦,并在团队成员之间进行优先排序。此外,开发人员还改进了部署流程,逐步减少了人工验证步骤,并更多地依赖于改进后的自动测试。最后,他们改用全自动部署,将部署时间从 40 分钟缩短到 4 分钟。
Booking.com 高级工程经理 Egor Savochkin 介绍了团队为降低变更时引入问题的风险并改进代码所采取的方法:
团队采用 Boy Scout rule,通过重构和测试自动化提高代码质量,同时不停止所有功能工作。在实施变更或修复缺陷的同时,还要努力改进周围的代码。这并不需要很大的改进。这可能只是简单地为你接触过的类添加单元测试,或进行小规模重构以消除代码质量问题。
在团队选择将单体应用程序拆分为微前端(MFE)后,前端方面也得到了改进,但改进并没有像希望的那样迅速实现。在调整代码审查流程并减少对外部专家审批的依赖后,代码审查时间缩短到了 8 分钟。有了快速的代码审查,团队开始更频繁地进行小规模部署,将部署时间缩短到 1 小时。