2019-09-05最大的困难有三个都在人的工作习惯上：有效且同期建设的单元测试;每天至少一次的push代码；轻量级频繁的code review作者回复: 第七篇文章会有一些相关讨论。希望对你能有些帮助。有问题继续讨论 ：）
1 7
2019-09-05使用git rebase的话，具体操作流程应该是
add /rm ->commit ->pull ->rebase ->push
这样子对吗作者回复: 对的。不过一般中间哪一个pull是使用fetch。因为pull会自动merge。所以，
add /rm ->commit ->fetch ->rebase ->push 2
2019-09-18使用大仓和组件化多仓的权衡关键主要是什么呢？作者回复: 这篇文章有不错的权衡列表：
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 1
2019-09-131. 在几千名开发人员共同使用一个大代码仓的工作方式下，做好 CI 有很大的挑战性。你觉得挑战在哪里，容易出现什么样的问题，又应该怎么解决呢？
最大的挑战有两个：1. 代码冲突如何处理。2. 模块之间的依赖如何解决。
对于1，首先是要改善团队文化，鼓励大家频繁提交，而不是只在每天下班前提交一次，其次，出现冲突，需要开发人员自己解决，这部分在做plan，最好能预留一些buffer，不然大家都在赶进度，都不会愿意去做，容易拖到最后，更不容易解决。
对于2，模块之间尽量松耦合，要保证模块之间的接口是稳定的。
2. 今天我提到了持续开发在 CI 中的作用，请你结合上一篇文章，思考一下持续开发和 CI/CD 是怎样互相促进的。
CI/CD的快速反馈，对于持续开发来说，是一个正向激励的作用，让开发人员对于正在开发的功能更有信心。展开作者回复: 非常好的答案！一点我的想法：
> ...首先是要改善团队文化，鼓励大家频繁提交，
这个推荐实时文章中的思路和办法
> ...而不是只在每天下班前提交一次...
是的。这个应该是做原子性的提交。做好一个马上就提交。而不是每天提一次的。另外，如果Commit比较大，可以每天都`git fetch; git rebase`一次，把最近一天的冲突在本地解决，然后继续在本地开发，直到commit 做完再提交 1- 2019-09-04持续集成、持续交付、持续部署的核心区别在我看来是自动化测试能力：
CI 每天多次将多人开发的代码合并到主干，并进行构建、代码检查、冒烟测试
CDelivery 自动将CI的结果打包、在测试环境和类生产环境进行自动化测试
CDeploy 自动将CDelivery的结果进行回归测试，并按照预设的灰度策略部署到生产环境作者回复: 嗯，可以这么理解。测试能力越强，可以自动化保证质量的地方就更多，就可以更快！
1 - 2020-02-02您好，我想请问在Facebook管理协作中，整个流水线的衔接、协作、融合、改进，是谁来推动的呢？或如何触发的呢？
2020-01-13大仓库的缺点1.cu的执行效率可能有影响，代码获取，单元测试等全面检查等耗时长;2.代码的分支管理和合并复杂
Fb会做增量单元测试或自动化测试吗？她们包含部署和自动化测试的流水线的耗时大概是多少？我们面临的问题是部署时间5～10分钟，极大影响的反馈效率作者回复: > Fb会做增量单元测试或自动化测试吗？
如果大仓不做增量测试增量检查的话，效率就会极低。所以FB大量使用这样的实践。在本地运行的测试和检查基本上全是增量的。流水线上的也有相当一部分是只运行增量检查。
> 她们包含部署和自动化测试的流水线的耗时大概是多少？
本地检查一分钟。本地就可以构建跟生产比较一致的环境。所以反馈效率很高。CI实践会长一些，大概一二十分钟。- 2019-10-13我再jenkins+gitlab+sonar做集成的时候，想通过Merge Requests触发代码检查，并且只检查请求合并的代码，这样能实现吗？有没有实现的教程可推荐呢？ 4
2019-09-17比如，一个需求是基于用户不同状态来衍生出来的需求。测试过程中，需要考虑各种用户可能存在的状态扭转，以及对应的测试。但是上线以后，还是会存在没有考虑到的历史存量用户因为长期的业务累积，出现了预期之外的状态。导致代码上线以后，需要回滚。
再者，因为是多个端开发实现，上线时有一定的顺序上线，那比如等到中间上线的应用出现了问题。再想要回滚时，可能因为数据库数据被更改了的原因，导致无法回滚。后续就只能通过修复代码，或者修复数据库的办法才能解决作者回复: > ...但是上线以后，还是会存在没有考虑到的历史存量用户因为长期的业务累积...
1- 2019-09-16请问facebook的性能测试平台和ci流程是怎么结合的？有专门的平台，还是这部分测试代码和单侧代码一样也是集成在工程里面随ci流程触发？
作者回复: 这个问题答案我不是100%确定。应该是集成在工程里面随CI流程触发的。而且并不是每一个CI都触发，因为比较昂贵和耗时。
2019-09-051 .在几千名开发人员共同使用一个大代码仓的工作方式下，做好 CI 有很大的挑战性。你觉得挑战在哪里，容易出现什么样的问题，又应该怎么解决呢？
容易出现代码合并冲突。出现冲突时的处理策略，回退or丢弃？冲突时，如何保证后续提交，可以正常合入？
功能依赖。功能模块大都不是独立的，如何保证双方一同合入？
代码功能冲突，大量冗余代码，一些功能可能会出现重复定义。
解决方案（我也不清楚，感觉需要一个好的架构师）展开作者回复: 请参考对Weining Cao问题的回复。
2019-09-05挑战在如何快速解决合并冲突。如何快速同步开发机器的代码保持最新。还有如果测试失败如何快速回滚。作者回复: > 挑战在如何快速解决合并冲突。
开发人员自己解决。提交做到原子性有很大帮助。
> 如何快速同步开发机器的代码保持最新。
经常`git fetch; git rebase origin/master`。
> 还有如果测试失败如何快速回滚。
1. 减少入库时的测试失败：多使用本地测试
2. 入origin/master库之后不会滚。写修复提交再赶紧push上去。实在不行，`git revert`命令产生一个新提交push上去。- 2019-09-04怎样提高自动测试的覆盖率和性能，会是很大的挑战，各模块开发者对其他模块不熟悉，发生bug的机率较高，测试覆盖到位比较难。
业务变化过程中，及时发现不必要的测试，提高测试性能也比较重要。作者回复: 我见到比较有效的方法是通过职责定位解决：每个团队对自己的模块负责，并不要求测试覆盖率。就是这么简单的办法就很有效。
比如，如果模块A依赖于模块B，那么首先A的作者会有意愿写一些针对A调用B的集成测试，因为这样的自动化方便在A的开发过程中，确保A的运行正确。
同样的，如果发现B有问题，B的作者会有意愿给B写单元测试和接口测试。因为在A的测试失败找到是B的责任时，B的自动化测试可以节省B的作者的Debug时间。
这样的方式，你觉得在你的团队会有成效吗？ 1 
2019-09-04持续部署的描述那个链接打不开了作者回复: 这个可能需要科学上网
2019-09-04持续序列流水线中进去下一个节点的标准是什么，实操中难点是，大家对自动化的结果没有信心，如何做到呢？作者回复: > 持续序列流水线中进去下一个节点的标准是什么，
所有的自动化测试通过。
> 实操中难点是，大家对自动化的结果没有信心，如何做到呢？
既然要使用流水线，我觉得只有逐步建设自动化测试。测试比较有效，大家才能真正用起来。否则这个流水线的价值就不大。- 2019-09-04大公司对接的业务复杂多变，很多线上故障都出现在一些没有预估到的流程。如何提高CI，如何全面自动化覆盖回归，这个是个很大的挑战。
作者回复: 能举一个“线上故障都出现在一些没有预估到的流程”具体又脱敏的例子吗？
2019-09-04大公司的流程就是规范哈。如果一个小公司几十人的团队，是不是没必要搞这么多自动化，流程化，规范化。。。？作者回复: 赞同加牛不辣的观点。补充一点，在小公司的时候，流程和规范应该比大公司少一些，更加灵活一些。
4
2019-09-04持续交付36讲专栏中说到持续交付包含持续集成和持续部署，老师你怎么看？作者回复: 持续集成是在持续交付里面的。持续部署，要看具体语境中，持续部署具体怎么定义的（方法论的东西比较tricky）。