研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?

葛俊 2019-09-04
你好,我是葛俊。
在上一篇文章中,我和你分享了代码入库前的流程优化,即持续开发。今天,我会继续与你介绍流程优化中,代码入库和入库后的 3 种持续工程方法,即持续集成(Continuous Integration, CI)、持续交付(Continuous Delivery, CD)和持续部署(Continuous Deployment, CD)。
在接下来的分享中,首先我会与你介绍这 3 种方法的定义和作用,帮助你深入理解这 3 个“持续”背后的原理和原则;然后我会以 Facebook 为参考,给你介绍基于这些原则的具体工程实践。我希望,这些内容能够帮助你用好这三个“持续”方法,提高团队的研发效能。
首先,我先来介绍一下,持续集成、持续交付和持续部署是用来解决什么问题的,也就是它们的定义和作用。

3 个“持续”的定义和作用

不知道你是否还记得,在开篇词中,我提到过一个低效能的情况,即产品发布上线时出现大量提交、合并,导致最后时刻出现很多问题。这个情况很常见,引起了很多用户的共鸣。产生这个问题最主要原因是,代码合并太晚。这里,我再与你详细解释一下原因。
当多个人同时开发一款产品的时候,很可能会出现代码冲突。而解决冲突,需要花费较多的时间;同时很可能出现冲突解决失败,导致产品问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • 刘晓光
    最大的困难有三个都在人的工作习惯上:有效且同期建设的单元测试;每天至少一次的push代码;轻量级频繁的code review

    作者回复: 第七篇文章会有一些相关讨论。希望对你能有些帮助。有问题继续讨论 :)

    2019-09-05
    1
    7
  • Geek_1988
    使用git rebase的话,具体操作流程应该是
    add /rm ->commit ->pull ->rebase ->push
    这样子对吗

    作者回复: 对的。不过一般中间哪一个pull是使用fetch。因为pull会自动merge。所以,
    add /rm ->commit ->fetch ->rebase ->push

    2019-09-05
    2
  • 詩鴻
    使用大仓和组件化多仓的权衡关键主要是什么呢?

    作者回复: 这篇文章有不错的权衡列表:
    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-18
    1
  • 日拱一卒
    1. 在几千名开发人员共同使用一个大代码仓的工作方式下,做好 CI 有很大的挑战性。你觉得挑战在哪里,容易出现什么样的问题,又应该怎么解决呢?
    最大的挑战有两个:1. 代码冲突如何处理。2. 模块之间的依赖如何解决。
    对于1,首先是要改善团队文化,鼓励大家频繁提交,而不是只在每天下班前提交一次,其次,出现冲突,需要开发人员自己解决,这部分在做plan,最好能预留一些buffer,不然大家都在赶进度,都不会愿意去做,容易拖到最后,更不容易解决。
    对于2,模块之间尽量松耦合,要保证模块之间的接口是稳定的。


    2. 今天我提到了持续开发在 CI 中的作用,请你结合上一篇文章,思考一下持续开发和 CI/CD 是怎样互相促进的。
    CI/CD的快速反馈,对于持续开发来说,是一个正向激励的作用,让开发人员对于正在开发的功能更有信心。

    作者回复: 非常好的答案!一点我的想法:

    > ...首先是要改善团队文化,鼓励大家频繁提交,
    这个推荐实时文章中的思路和办法

    > ...而不是只在每天下班前提交一次...
    是的。这个应该是做原子性的提交。做好一个马上就提交。而不是每天提一次的。另外,如果Commit比较大,可以每天都`git fetch; git rebase`一次,把最近一天的冲突在本地解决,然后继续在本地开发,直到commit 做完再提交

    2019-09-13
    1
  • Geek_93f953
    持续集成、持续交付、持续部署的核心区别在我看来是自动化测试能力:
    CI 每天多次将多人开发的代码合并到主干,并进行构建、代码检查、冒烟测试
    CDelivery 自动将CI的结果打包、在测试环境和类生产环境进行自动化测试
    CDeploy 自动将CDelivery的结果进行回归测试,并按照预设的灰度策略部署到生产环境

    作者回复: 嗯,可以这么理解。测试能力越强,可以自动化保证质量的地方就更多,就可以更快!

    2019-09-04
    1
  • 宝宝太喜欢极客时间了
    我再jenkins+gitlab+sonar做集成的时候,想通过Merge Requests触发代码检查,并且只检查请求合并的代码,这样能实现吗?有没有实现的教程可推荐呢?
    2019-10-13
    3
  • 高倩
    比如,一个需求是基于用户不同状态来衍生出来的需求。测试过程中,需要考虑各种用户可能存在的状态扭转,以及对应的测试。但是上线以后,还是会存在没有考虑到的历史存量用户因为长期的业务累积,出现了预期之外的状态。导致代码上线以后,需要回滚。

    再者,因为是多个端开发实现,上线时有一定的顺序上线,那比如等到中间上线的应用出现了问题。再想要回滚时,可能因为数据库数据被更改了的原因,导致无法回滚。后续就只能通过修复代码,或者修复数据库的办法才能解决

    作者回复: > ...但是上线以后,还是会存在没有考虑到的历史存量用户因为长期的业务累积...

    2019-09-17
    1
  • lisa
    请问facebook的性能测试平台和ci流程是怎么结合的?有专门的平台,还是这部分测试代码和单侧代码一样也是集成在工程里面随ci流程触发?

    作者回复: 这个问题答案我不是100%确定。应该是集成在工程里面随CI流程触发的。而且并不是每一个CI都触发,因为比较昂贵和耗时。

    2019-09-16
  • 师傅又被抓走了
    1 .在几千名开发人员共同使用一个大代码仓的工作方式下,做好 CI 有很大的挑战性。你觉得挑战在哪里,容易出现什么样的问题,又应该怎么解决呢?
    容易出现代码合并冲突。出现冲突时的处理策略,回退or丢弃?冲突时,如何保证后续提交,可以正常合入?
    功能依赖。功能模块大都不是独立的,如何保证双方一同合入?
    代码功能冲突,大量冗余代码,一些功能可能会出现重复定义。

    解决方案(我也不清楚,感觉需要一个好的架构师)

    作者回复: 请参考对Weining Cao问题的回复。

    2019-09-05
  • Weining Cao
    挑战在如何快速解决合并冲突。如何快速同步开发机器的代码保持最新。还有如果测试失败如何快速回滚。

    作者回复: > 挑战在如何快速解决合并冲突。
    开发人员自己解决。提交做到原子性有很大帮助。

    > 如何快速同步开发机器的代码保持最新。
    经常`git fetch; git rebase origin/master`。

    > 还有如果测试失败如何快速回滚。
    1. 减少入库时的测试失败:多使用本地测试
    2. 入origin/master库之后不会滚。写修复提交再赶紧push上去。实在不行,`git revert`命令产生一个新提交push上去。

    2019-09-05
  • Geek_1988
    怎样提高自动测试的覆盖率和性能,会是很大的挑战,各模块开发者对其他模块不熟悉,发生bug的机率较高,测试覆盖到位比较难。

    业务变化过程中,及时发现不必要的测试,提高测试性能也比较重要。

    作者回复: 我见到比较有效的方法是通过职责定位解决:每个团队对自己的模块负责,并不要求测试覆盖率。就是这么简单的办法就很有效。

    比如,如果模块A依赖于模块B,那么首先A的作者会有意愿写一些针对A调用B的集成测试,因为这样的自动化方便在A的开发过程中,确保A的运行正确。

    同样的,如果发现B有问题,B的作者会有意愿给B写单元测试和接口测试。因为在A的测试失败找到是B的责任时,B的自动化测试可以节省B的作者的Debug时间。

    这样的方式,你觉得在你的团队会有成效吗?

    2019-09-04
    1
  • Johnson
    持续部署的描述那个链接打不开了

    作者回复: 这个可能需要科学上网

    2019-09-04
  • 飞奔的骆驼
    持续序列流水线中进去下一个节点的标准是什么,实操中难点是,大家对自动化的结果没有信心,如何做到呢?

    作者回复: > 持续序列流水线中进去下一个节点的标准是什么,
    所有的自动化测试通过。

    > 实操中难点是,大家对自动化的结果没有信心,如何做到呢?
    既然要使用流水线,我觉得只有逐步建设自动化测试。测试比较有效,大家才能真正用起来。否则这个流水线的价值就不大。

    2019-09-04
  • 高倩
    大公司对接的业务复杂多变,很多线上故障都出现在一些没有预估到的流程。如何提高CI,如何全面自动化覆盖回归,这个是个很大的挑战。

    作者回复: 能举一个“线上故障都出现在一些没有预估到的流程”具体又脱敏的例子吗?

    2019-09-04
  • 李双
    大公司的流程就是规范哈。如果一个小公司几十人的团队,是不是没必要搞这么多自动化,流程化,规范化。。。?

    作者回复: 赞同加牛不辣的观点。补充一点,在小公司的时候,流程和规范应该比大公司少一些,更加灵活一些。

    2019-09-04
    4
  • Robert小七
    持续交付36讲专栏中说到持续交付包含持续集成和持续部署,老师你怎么看?

    作者回复: 持续集成是在持续交付里面的。持续部署,要看具体语境中,持续部署具体怎么定义的(方法论的东西比较tricky)。

    2019-09-04
收起评论
16
返回
顶部