写点什么

Spotify 高质量工程生产力实践

作者:俞凡
  • 2022-12-03
    上海
  • 本文字数:2588 字

    阅读完需:约 8 分钟

对于大规模团队来说,开发体验将直接影响到产品质量和迭代速度。本文介绍了 Spotify 工程团队通过打造统一的开发平台,赋能开发团队,实现高质量工程生产力的经验。原文: Quality Engineering Productivity at Spotify



编程可能是一场噩梦。


并不是说编写代码本身痛苦,而是说整体体验。


组织的关注点是迅速发现什么东西对用户更重要,但这必然引入更多的技术、更多的问题


软件工程师在解决配置、部署或其他集成问题时浪费了大量时间,而解决这些问题实际上并没有交付新的价值。


质量工程的作用就在于保证软件价值链实现即快又好(Quality at Speed)


本文将分享 Spotify 如何在痛苦的环境中实现高质量的工程生产率。

为什么需要实现高质量工程生产力

Spotify 的工程师必须快速试验、学习并推出新功能。


速度是由拥有所有必要技能的跨职能团队实现的,这些团队可以高度自主的发布功能。


这是他们对即快又好(Quality at Speed) 的定义:


"迅速将创意转化为产品,并尝试改善用户体验,进入新的市场,并保持作为流媒体内容提供商的竞争力。"


虽然专注于速度在一开始有效,但每个团队都因工程实践的不同以及技术的分散积累了技术债务。


图 1: 生产率的速度和标准悖论,来自 Backstage。


高质量工程生产力意味着即快又好(Quality at Speed) 的保持迭代,平衡速度与标准的要求。


平台开发者体验(Platform Developer Experience) 团队是负责保证工程师能够实现大规模快速迭代的主要力量。

质量工程加速开发人员体验

成功的开发体验(Developer Experience)工程生产力(Engineering Productivity) 驱动。


Spotify 将他们的体验称为"传言驱动开发(rumor-driven development)",当时让软件工作的唯一方法是询问附近的人并遵循传言。


新开发人员的入职时间长达60天


这与有效的开发体验相去甚远,并影响了团队规模。


为此,Spotify 通过以下方式专注于提高高质量的工程生产力:


  • 衡量投入产出比;

  • 不断将产出与结果联系起来;

  • 为了更多的产出和更多的结果而不断改进。


"为了理解如何帮助 Spotify 团队快速完成实验,我们需要了解他们是如何工作的。" ——How We Improved Developer Productivity for Our DevOps Teams,Spotify 工程团队。


平台开发者体验团队为每个用例提供可重复的组件化产品,从而优化开发周期。


接下来看看这个团队提供了什么来消除开发的干扰。

Spotify 的高质量工程生产力组件

跨职能团队需要 14 天来运行新创建的应用程序,这太慢了。


基础设施团队致力于创建快速稳定的软件工件抽象,工程师可以根据需要利用这些工件。


他们构建了以下产品:


  • Backstage,为软件工程师提供一站式服务;

  • Golden Paths,提供标准引导教程;

  • Tingle CI/CD,构建、部署和发布平台;

  • 测试认证计划,提供测试评估。


这些组件将服务配置的时间从 14 天缩短到不到 5 分钟。


例如,开发人员可以在一天内得到一个像 Spotify 这样的网站框架,包含 URL、存储库、CI/CD。

Golden Paths 作为 Backstage 的一站式商店

减少决策数量可以支持可伸缩和快速流程。


Golden Path 是构建某些固定的、被支持的东西的路径(例如,构建后端服务、建立网站、创建数据流水线)。


Golden Path 提供了在Backstage门户上可用的逐步引导的教程。


图 2: 在 Spotify 的 Backstage 可用的应用程序引导。


软件工程师可以通过"Golden Path",遵循基于最佳实践的分步向导,构建出标准应用程序。


多年来,Golden Path 教程随着客户端开发、数据工程、数据科学、机器学习、音频处理、web 等的发展而发展。


曾几何时,Spotify 的工程师无法想象会有"Golden Path"的生活,而现在他们无法想象没有"Golden Path"的生活。

基于 Tingle 进行系统构建、部署和发布管理

一旦项目在工程师的笔记本电脑上运行,接下来就面临怎样将应用部署到生产环境的集成问题。


Tingle 是一个 CI/CD 系统,可以自动构建推送到 GitHub 的代码,并通过 Backstage 向开发人员提供反馈。


所有这些都不需要理解如何配置构建流水线。


图 3: CI/CD 平台必须简化整个流程,来自 AWS。


如果通过了所有测试,Tingle 将利用常规 GitHub 工作流,自动完成构建、测试、打包的工作,并将变更部署到生产环境中。


Spotify 用 Tingle 替换了超过 200 台独立 Jenkins 服务器,每周运行超过数万个构建。


但仍缺乏部署的信心。

测试认证计划,更有信心交付

Spotify 的工程师们依靠游戏化来让代码接受适当的测试。


每个主要的工程领域都有一个测试认证计划:


  • 提供质量控制合规性检查;

  • 提供关于构建时间、代码覆盖率和可靠性的测试报告;

  • 当代码包含不可靠的测试(即 flaky 测试)时,向团队发出告警;

  • 根据认证级别在服务旁边提供徽章。


图 4: 测试认证计划和质量闸门,来自 Spotify 工程团队。


测试认证计划促进了支持加速软件交付周期的测试套件的创建。


从 2018 年开始,团队遇到的阻塞问题以及其他类型的反应性工作大幅减少。


在这么大的自主权下,这一切是如何运作的?

自治团队的高质量工程生产力

Golden Paths、Tingle 和测试认证计划有助于将技术栈标准化。


但 Spotify 让团队自由选择适合自己团队运作方式的工具和方法。


因此,质量工程平台需要通过成熟的模块化来保证让开发团队持续采用。


图 5: Spotify 的质量工程平台服务。


每个团队都可以自主决定是否使用所有平台服务,而这一切取决于平台提供的附加价值。


这就形成了一个生态系统,在这个生态系统中,只有即快又好(Quality at Speed) 的组件仍在使用。

即快又好的高质量工程生产力

Spotify 朝着即快又好(Quality at Speed) 的方向加速前进,建立了高质量工程生产力(Quality Engineering Productivity)


对于在职以及新入职工程师来说,构建一个项目只需要不到 5 分钟的时间,从而支持组织规模的壮大。


集成了系统测量和告警的认证程序不断提高工程生产力。


Spotify 学会了把事情简单化:


  • 每个组件保留一条 Golden Path,避免子模块;

  • 记录当前路径(即使当前很痛苦),然后进行优化;

  • 培养用户对平台工具的持续使用和反馈;


Backstage现在已经开源,并提供对 100 多个系统的集成,Zalando、Unity 和 Expedia 等公司都在使用。


当前的改进方向是基于 Golden State 使 Golden Path 自动与项目一致,并保持良好的文档级别。


Golden Path 是 Spotify 最受欢迎和使用最多的技术文档,是一个真正的质量工程成就。


准备好构建你的高质量工程生产力了吗?




你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。微信公众号:DeepNoMind

发布于: 刚刚阅读数: 3
用户头像

俞凡

关注

公众号:DeepNoMind 2017-10-18 加入

俞凡,Mavenir Systems研发总监,关注高可用架构、高性能服务、5G、人工智能、区块链、DevOps、Agile等。公众号:DeepNoMind

评论

发布
暂无评论
Spotify高质量工程生产力实践_DevOps_俞凡_InfoQ写作社区