24 | 快速反馈：为什么你们公司总是做不好持续集成？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
持续集成的关键在于快速反馈和有效的反馈。本文强调了在本地环境执行各种检查的重要性，以及在团队协作中遵守提交纪律的必要性。为了实现快速反馈，文章提出了持续集成监视器的重要性，通过即时、引人注目的反馈方式来提高持续集成的关注度。此外，文章还提到了持续集成的纪律要求，如只有CI服务器处于绿色状态才能提交代码，以及一旦CI服务器检查出错，要立即修复。总之，做好持续集成的关键在于快速反馈和有效的反馈，而实现这一点需要团队的共同努力和遵守一定的纪律。
《10x 程序员工作法》，新⼈⾸单¥68
全部留言(29)
- 最新
- 精选
- 操盘手爱德华诸位看的时候别忘了，虽然老师说了别人修复之前不能提交。但是后面还有一句，如果一时半会儿修不好，应该撤掉提交
作者回复: 很好的关注点
2019-12-1327 
Luke郑大文中提到工作中「心流」，在这里想要补充一下：Bob 大叔（Robot. C. Martin）认为「心流」仅适用于练习，而非正式的工作中的编码。「代码整洁之道—程序员的职业素养」中曾提到，开发人员在开发时应该避免进入这种状态，「心流」仅适用于练习，因为它会「将视野收拢到狭窄的状态」。 抄录原文如下： 一些曾经进入这种状态但最终又从中摆脱出来的人给出了一点儿忠告：避免进入流态区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种「浅层冥想」状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。... ... 如果你当时正在做 TDD，你会快速地重复「红/绿/重构」循环。你会收获一种愉悦感或征服感。问题在于，在流态区状态下，你其实放弃了顾及全局，因此，你很可能会做出一些后来不得不推倒重来的决策。在流态区写代码可能会快些，但是后面你将不得不更多地回头重新审视这些代码。作者回复: 很好的补充
2021-06-2111
西西弗与卡夫卡有启发。常遇到的问题是，项目多了以后CI资源吃紧要排队。虽然可以自己用本地多做事，但这有点像“公地悲剧”，只是自己节约还不够，会被别人挤占资源，所以大家抢着上，结果大家都慢。如果有智能CI可以依据以往占用资源的多少来分配CI优先级，或许可以缓解。当然，不差钱的话，增加机器可能更简单作者回复: 能花钱解决的事都是小事，一个程序员比一台机器贵多了。
2019-02-279
孤星可快速反馈这个观点是很赞同的 本地验证这个个人不太看好 以普通 JAVA 项目为例 本地跑一次 耗时以分钟计 这个间隔有点长了作者回复: 如果你的本地检查可以在几分钟内完成，那就是可以在本地做的，因为你把它放到 CI 服务器上执行，效果只会更差，而且几分钟时间，稍作调整也并无不可。 如果时间很长，比如，超过十分钟，根据快速反馈的原则，就要考虑是不是考虑按照测试金字塔划分一下，在本地只跑单元测试。 但实际情况是，很多团队没有真正的单元测试，造成本地只能运行集成测试，甚至是验收测试，所以，会占据很长时间。
2019-02-278
eyeandroid老师，我的意思是其它人的提交被CI检查出错后只会影响他这笔提交，并不会block其它人的提交，所以并不会存在等待其它人修复这个说法，请教下我的理解对吗？因为我工作中遇到的情况是这样作者回复: 谁破坏谁修复，CI 红的时候，除了修复的人，任何人不允许提交。这时如果有人已经完成代码准备提交，破坏 CI 的人就是阻塞了它人的工作，所以，要尽快修复。
2019-02-2724- eyeandroidCI 服务器一旦检查出错，要立即修复。原因很简单，你不修，别人就不能提交，很多人的工作就会因此停顿下来，团队的工作流就会被打断，耽误的是整个团队的工作。 老师，请教下上面这句话我不太理解。我在工作中遇到的CI是针对某笔提交的，某笔提交被CI服务器检查出错只会影响他这笔的提交，其它人可以继续做检查提交。
作者回复: 一次一个提交，出错了容易修复，等这次 CI 通过了，下个人再来提交。强调本地检查，就是说，CI 的运行不会影响你在本地工作。把事情做小，做简单，这是我们在任务分解模块的主要观点，前面学的原则，后面也要用啊！
2019-02-274 
行与修如果单元测试做的不到位，或者不满足A-TRIP，是不是执行CI的效果就会弱很多？ 另外在持续集成的过程中，测试人员或者QA有可能参与其中吗？如果能参与的话，对他们的意义以及他们的贡献会是什么？作者回复: 说得没错，测试是基础，自动化是基础，CI是一根主线，将诸多实践贯穿起来。 CI强调自动化，测试人员不需要参与到其中。但测试人员可以拿到生成物去测试，找到的问题以测试的形式补充进来。
2019-03-012- 笨猪本地执行所有测试有点慢怎么办？ 郑老师好，您在文章中提到在本地执行CI服务器相同的动作，那么当执行所有的检查花费时间较久时（比如超过5分钟），那么是不是也是打断了心流呢？这种问题怎么破？
作者回复: 本着“快速反馈”为原则，本地测试执行慢，我们就要分析执行慢的缘由是什么。 常见的问题有，集成测试太多，那就要增加单元测试的量，把集成测试的运行放在 CI 服务器上；“单元”测试不是单元测试，可以参考前面关于测试应该写成什么样；模块太大，里面包含了太多的内容，可以考虑做模块的拆分等等。 只有当你知道了问题是什么，才能有效地解决问题。
2020-06-061 
Xunqf我们团队比较小，开发流程比较野路子，都是刚毕业的大学生，没多少开发经验，我们目前的开发流程是: 代码用GitHub托管，然后我们也用到了Jenkins，但是作为一个移动开发来说，对Jenkins的了解还仅限于自动打包工具，由于一开始使用的是手动打包，每次打一个包都要费好长时间，后来了解到自动打包，就很公司申请了一台电脑，用Jenkins搭建了一个自动打包服务器，然后定时去GitHub拉取代码打包，打包成功后上传蒲公英，然后发邮件通知下载，还不存在老师说的出错了就影响其他人提交的问题，感觉我们的持续集成是在GitHub上，缺失了测试环节。听老师讲完感觉我们做的太简单了，但是老师说的这些服务公司根本就没有，现有的这么简单的东西还是我们自己抽时间搞的，但是我们的主要任务毕竟是开发公司的业务产品，而Jenkins持续集成服务也非我专长，不太可能花太多精力去做这个。这个时候我该怎么办？作者回复: 其实，CI 不应该占用那么长时间，在构建脚本里写好打包过程，在 CI 服务器上调用一下就好了。至于 CI 监视器，网上有很多，找一个现成的拿来用就好了。
2019-03-031
清菊我们遇到的问题是UI测试结果不稳定，这样的话是直接去掉这部分的测试吗？作者回复: 难道不是把测试修好，让它稳定下来吗？关于测试应该是什么样，我们在前面讲过。
2019-02-271
