06 | 代码入库到产品上线：Facebook如何使用CI/CD满足业务要求？
该思维导图由 AI 生成，仅供参考
3 个“持续”的定义和作用
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Facebook在代码入库到产品上线的流程中，采用了持续集成（CI）、持续交付（CD）和持续部署（CD）这三种持续工程方法。这些方法的出发点是解决代码合并导致的低效能问题，通过尽早、频繁地将代码推送到共享的代码仓库分支上，减少代码冲突造成的问题。Facebook注重运行大量高质量的测试和检查，以及投入硬件资源、使用增量测试等方式来提高流水线的速度。Facebook在CI方面加强持续开发，让开发人员能在开发环境上进行大量的验证，同时使用Phabricator作为CI的驱动，并作为质量检查中枢，尽量提高入库前代码审查的流畅性。在持续交付方面，Facebook使用大仓，同一个仓中每天有几千个代码提交，因此采用了按照一定时间间隔进行验证的方式，同时对验证进行分级。在持续部署方面，Facebook极致地进行自动化测试验证，采用类似持续交付的方法，把一段时间之内的提交一起部署。Facebook的实践为读者提供了具体的原则和最佳实践，帮助他们加深理解并应用这些方法来提高团队的研发效能。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(27)
- 最新
- 精选
刘晓光最大的困难有三个都在人的工作习惯上：有效且同期建设的单元测试;每天至少一次的push代码；轻量级频繁的code review作者回复: 第七篇文章会有一些相关讨论。希望对你能有些帮助。有问题继续讨论 ：）
2019-09-05211
技术修行者
1. 在几千名开发人员共同使用一个大代码仓的工作方式下，做好 CI 有很大的挑战性。你觉得挑战在哪里，容易出现什么样的问题，又应该怎么解决呢？ 最大的挑战有两个：1. 代码冲突如何处理。2. 模块之间的依赖如何解决。 对于1，首先是要改善团队文化，鼓励大家频繁提交，而不是只在每天下班前提交一次，其次，出现冲突，需要开发人员自己解决，这部分在做plan，最好能预留一些buffer，不然大家都在赶进度，都不会愿意去做，容易拖到最后，更不容易解决。 对于2，模块之间尽量松耦合，要保证模块之间的接口是稳定的。 2. 今天我提到了持续开发在 CI 中的作用，请你结合上一篇文章，思考一下持续开发和 CI/CD 是怎样互相促进的。 CI/CD的快速反馈，对于持续开发来说，是一个正向激励的作用，让开发人员对于正在开发的功能更有信心。作者回复: 非常好的答案！一点我的想法： > ...首先是要改善团队文化，鼓励大家频繁提交， 这个推荐实时文章中的思路和办法 > ...而不是只在每天下班前提交一次... 是的。这个应该是做原子性的提交。做好一个马上就提交。而不是每天提一次的。另外，如果Commit比较大，可以每天都`git fetch; git rebase`一次，把最近一天的冲突在本地解决，然后继续在本地开发，直到commit 做完再提交
2019-09-136
于小咸使用git rebase的话，具体操作流程应该是 add /rm ->commit ->pull ->rebase ->push 这样子对吗作者回复: 对的。不过一般中间哪一个pull是使用fetch。因为pull会自动merge。所以， add /rm ->commit ->fetch ->rebase ->push
2019-09-0536
詩鴻使用大仓和组件化多仓的权衡关键主要是什么呢？作者回复: 这篇文章有不错的权衡列表： https://dev.to/pavanbelagatti/what-do-you-prefer-and-why-mono-repo-or-multiple-repositories-401b 从我的经验看，大仓的最大挑战是代码仓太大之后，会让很多操作性能下降。而git本身对代码仓中的子文件夹的支持不好。如果能克服这个挑战，使用大仓非常好！ 一些推荐的解决办法： https://www.perforce.com/blog/hth/multiple-git-repositories-whats-best-way-manage-them
2019-09-1822
陈斯佳终于搞懂了持续交付和持续部署的区别，主要就是前者仅限于非生产环境，目的是随时随地提供可部署的软件；后者则是直接部署到生产环境中。看老师的观点，也就是提交量很大的情况才会考虑到持续部署。鉴于我们公司的提交量还处于excel checklist的可以摆平的状况，持续部署应该在很长的时间内不需要我去担心了……重点关注持续集成和持续交付上作者回复: 是的，只有一部分公司需要持续部署。
2020-04-071
Lu老师您好～ 我所在的组织在尝试CICD流水线从而实现云上部署。CI流水线这一步每次都会有安全漏洞检查，单这个检查本身耗时很久，而且还需要等待排队，解决这个问题可以从哪些方面入手呢？谢谢。作者回复: 这个可以从几个方面入手： 1. 提高安全检查时间。如果能做到增量代码检查（只检查改变的代码涉及的部分）就可以大大提高效率 2. 降低运行安全检查的频率。参考第六篇文章的“基本原则 2：流水线的运行速度一定要快”部分。我们可以考虑不要对每一个代码入库都运行安全漏洞检查，而是每个一段时间运行一次。如果发现问题再从上一次检查的提交到这一次检查的提交之间用折半查找去找到有问题的提交进行修复。
2020-03-181- GeekJ您好，我想请问在Facebook管理协作中，整个流水线的衔接、协作、融合、改进，是谁来推动的呢？或如何触发的呢？
作者回复: 触发主要是1. 代码进入代码检查中心Phabricator。实际上Phabricator是流水线的神经中枢。代码入库之前，开发者会把改动发送到Phabricator，这会触发代码审查和机器检查流水线。2. 代码入库（git server）后Phabricator会监控到，然后出发各种流水线。3. 同时流水线还有定时的触发。比如每隔一段时间构建、运行测试、部署到一个测试环境上。 改进、融合的工作主要是工程师团队和Infrastructure团队共同推动。工程师团队会有需求，他们可以自己改进，当然更多是Infrastructure团队改进。Infrastructure团队也会考虑改进。工具部门就是Infra的一部分。
2020-02-021 - 于小咸怎样提高自动测试的覆盖率和性能，会是很大的挑战，各模块开发者对其他模块不熟悉，发生bug的机率较高，测试覆盖到位比较难。 业务变化过程中，及时发现不必要的测试，提高测试性能也比较重要。
作者回复: 我见到比较有效的方法是通过职责定位解决：每个团队对自己的模块负责，并不要求测试覆盖率。就是这么简单的办法就很有效。 比如，如果模块A依赖于模块B，那么首先A的作者会有意愿写一些针对A调用B的集成测试，因为这样的自动化方便在A的开发过程中，确保A的运行正确。 同样的，如果发现B有问题，B的作者会有意愿给B写单元测试和接口测试。因为在A的测试失败找到是B的责任时，B的自动化测试可以节省B的作者的Debug时间。 这样的方式，你觉得在你的团队会有成效吗？
2019-09-0421 - Geek_93f953持续集成、持续交付、持续部署的核心区别在我看来是自动化测试能力： CI 每天多次将多人开发的代码合并到主干，并进行构建、代码检查、冒烟测试 CDelivery 自动将CI的结果打包、在测试环境和类生产环境进行自动化测试 CDeploy 自动将CDelivery的结果进行回归测试，并按照预设的灰度策略部署到生产环境
作者回复: 嗯，可以这么理解。测试能力越强，可以自动化保证质量的地方就更多，就可以更快！
2019-09-041 - oliver增量测试有个问题，如果是较大范围的代码重构，如何确定增量测试的边界呢？
作者回复: 这个跟平时的改动差不多呀，就针对每一处改动，找到相关的依赖，都运行测试。
2020-04-22
