(点击放大图像)
这一系列博客文章将介绍促进领英内部数百位工程师的创新精神,帮助他们以敏捷、高质量、高效率地方式持续发布新软件所使用的工程基础架构(技术、过程、工具、文化)。这是系列文章的第一篇,将概括介绍整体架构、工作流,以及规模。
如上图所示,领英针对iOS 和Android 开发了原生应用,以及针对移动和桌面浏览器的linkedin.com 网站。这四类客户端均调用同一套共享的API 前端,借此与领英的各种中间层和后端服务交换数据。四种客户端提供了高度一致且类似的用户体验和功能。
我们使用了四个主代码库(Repo),每个对应一个平台:iOS、Android、Web(移动和桌面浏览器客户端共享同一个代码库以及大部分逻辑),以及API。每个主代码库还包含十几个专门针对特定个平台开发的库(Library)代码库。四个主代码库每个包含超过5,000 个文件,代码行数均超过50 万行,总共有大约200 个人负责提交代码。一个代码库的提交速率峰值约为每小时15 次,每天60 次,每周250 次。我们使用了主干开发(Trunk development)的模式,即每个代码库只有一个分支,每个人的提交,以及我们的发布操作都从这一个分支进行,每天会进行多次。
代码流程大致如下图所示,每个步骤和整个流程会多次进行迭代:
(点击放大图像)
- 为重大功能制定架构设计文档,并且必须通过设计审阅。
- 所有功能进行自动化测试,大部分功能具备 Sphinx 文档。功能、测试和文档均提交至同一个代码库。
- 所有代码变更须进行代码审阅,并需要同时通过所有者 ACL(访问控制列表以及每个文件的所有者)和平台 ACL(访问控制列表,并通过专家确保代码完整性、一致性,以及在特定平台上的最佳实践遵循情况)进行“发布”。
- 在预提交提交阶段,将代码正式提交至代码库之前,每次提交必须通过代码库中进行的静态分析、构建,以及自动化测试(单位 / 布局 / 场景,每个代码库共进行了约 4,000 次测试,且数量还在增加中)。如果预提交阶段有任何步骤失败,提交将被拒绝。同时进行的多个提交可并发执行预提交流程。
- 一旦提交至代码库,提交的内容必须通过提交后阶段相同(甚至更严格)的一系列测试,以确保所有提交在合并后依然可以为每次提交生成高质量、可发布的构建。如果提交后测试失败,提交可能被自动恢复,或由随时待命的工程师立刻修复。如果提交后测试成功,构建将被发布至 Artifactory 等待发布给用户设备(iOS 和 Android)或部署至生产站点(Web 和 API)。
- 对于 iOS 和 Android,每次成功的构建会通过应用内置的更新功能立刻发布给 Alpha 渠道(移动团队)。每周会有一个 iOS 构建和三个 Android 构建通过 MDM(移动设备管理)系统、应用内置的更新功能、TestFlight(iOS)或 Play Store(Android)的 Beta 渠道发布给 Beta 渠道(公司员工和 Beta 公测用户)。如果没发现什么严重问题,每周三我们会将某一个 Beta 构建通过 Apple 的 App Stora 和 Google 的 Play Store 发布给生产渠道(所有领英用户)。
- 对于 Web 和 API,每次成功的构建会自动部署至负责运行自动化测试的 EI 和 Staging(测试环境)。如果运行通过,该构建会自动部署至生产环境的金丝雀(Canary)设备,通过这些设备为请求提供服务,并与其他生产设备进行对比,通过各种度量值(HTTP 200/400/500 返回代码、异常、Fanout、延迟等)进行统计分析,这一过程也叫做 EKG。如果 EKG 通过,待命工程师会将其部署至生产环境,随后队列中的下一个构建将成为下一个候选部署。我们会在每个工作日的大约早 9 点、12 点,以及下午 3 点进行部署。
- 所有新功能和 WIP(Work In Progress,未完工程)均可得到 LiX’es( LinkedIn eXperiment )的保护,因此开发过程中只能被相应的功能团队所访问,随后将逐渐扩大至公司或公开范围,借此征集反馈并进行 A/B 测试,如果发现重大问题会立刻撤回。一旦全面推出,为确保代码库整洁和易于维护,还必须移除 LiX’es。
我们将这种工程过程称之为“3x3”:每天发布三次,代码提交时间和最终发布给用户的时间之间不超过三小时!
作者: Ning Zhang ,阅读英文原文: Engineering Infrastructure at Scale: Overview
感谢陈兴璐对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论