2019-02-27快速反馈这个观点是很赞同的 本地验证这个个人不太看好 以普通 JAVA 项目为例 本地跑一次 耗时以分钟计 这个间隔有点长了作者回复: 如果你的本地检查可以在几分钟内完成，那就是可以在本地做的，因为你把它放到 CI 服务器上执行，效果只会更差，而且几分钟时间，稍作调整也并无不可。
如果时间很长，比如，超过十分钟，根据快速反馈的原则，就要考虑是不是考虑按照测试金字塔划分一下，在本地只跑单元测试。
但实际情况是，很多团队没有真正的单元测试，造成本地只能运行集成测试，甚至是验收测试，所以，会占据很长时间。 4
2019-02-27老师，我的意思是其它人的提交被CI检查出错后只会影响他这笔提交，并不会block其它人的提交，所以并不会存在等待其它人修复这个说法，请教下我的理解对吗？因为我工作中遇到的情况是这样作者回复: 谁破坏谁修复，CI 红的时候，除了修复的人，任何人不允许提交。这时如果有人已经完成代码准备提交，破坏 CI 的人就是阻塞了它人的工作，所以，要尽快修复。
1 2- 2019-02-27CI 服务器一旦检查出错，要立即修复。原因很简单，你不修，别人就不能提交，很多人的工作就会因此停顿下来，团队的工作流就会被打断，耽误的是整个团队的工作。
老师，请教下上面这句话我不太理解。我在工作中遇到的CI是针对某笔提交的，某笔提交被CI服务器检查出错只会影响他这笔的提交，其它人可以继续做检查提交。作者回复: 一次一个提交，出错了容易修复，等这次 CI 通过了，下个人再来提交。强调本地检查，就是说，CI 的运行不会影响你在本地工作。把事情做小，做简单，这是我们在任务分解模块的主要观点，前面学的原则，后面也要用啊！
2 
2019-02-27有启发。常遇到的问题是，项目多了以后CI资源吃紧要排队。虽然可以自己用本地多做事，但这有点像“公地悲剧”，只是自己节约还不够，会被别人挤占资源，所以大家抢着上，结果大家都慢。如果有智能CI可以依据以往占用资源的多少来分配CI优先级，或许可以缓解。当然，不差钱的话，增加机器可能更简单作者回复: 能花钱解决的事都是小事，一个程序员比一台机器贵多了。
2
2019-03-01如果单元测试做的不到位，或者不满足A-TRIP，是不是执行CI的效果就会弱很多？
另外在持续集成的过程中，测试人员或者QA有可能参与其中吗？如果能参与的话，对他们的意义以及他们的贡献会是什么？作者回复: 说得没错，测试是基础，自动化是基础，CI是一根主线，将诸多实践贯穿起来。
CI强调自动化，测试人员不需要参与到其中。但测试人员可以拿到生成物去测试，找到的问题以测试的形式补充进来。 1
2019-02-27我们遇到的问题是UI测试结果不稳定，这样的话是直接去掉这部分的测试吗？作者回复: 难道不是把测试修好，让它稳定下来吗？关于测试应该是什么样，我们在前面讲过。
1- 2019-12-13诸位看的时候别忘了，虽然老师说了别人修复之前不能提交。但是后面还有一句，如果一时半会儿修不好，应该撤掉提交
2019-12-09我一直有一个疑问！很多专栏都提到了持续集成，都表达了持续集成中包含自动化测试，我很想知道如果包含了接口和ui的测试，那么持续集成其实也是包括部署环节的。再就是持续集成服务器是监控主干还是分支和主干同时监控？
2019-11-14我每天在公司强调的，热手性- 2019-11-14本质是尽早得到反馈，早发现问题。
2019-05-30今天这节课老师真的是解决了我一个在工作上一直在思考的大问题，就是之前一直有个执念，想推程序员使用CI服务器来进行构建，但是发现很吃力，现在才知道，其实更好的方法是让他们先在本地进行构建，等代码检查无误再推到ci服务器上，这样子更加科学。- 2019-05-23公司没有CI的，表示瑟瑟发抖
2019-04-25可视化CI监视器可以了解下
2019-04-06打卡
2019-04-03持续集成和持续发布是绑定的，这样只要你发布就必须解决集成问题。
持续集成之前的代码合并倒是需要更多的约定和规范，好多时候有人强制提交。
是git分支策略选择，以及代码合并方法也对持续集成有重大影响
2019-03-11要让团队认识到复盘的重要性。
让每个人都深入思考项目运作过程中遇到了哪些问题。才能做好复盘。作者回复: 可执行的方案是定期回顾，做多了就懂了。
2019-03-03我们团队比较小，开发流程比较野路子，都是刚毕业的大学生，没多少开发经验，我们目前的开发流程是: 代码用GitHub托管，然后我们也用到了Jenkins，但是作为一个移动开发来说，对Jenkins的了解还仅限于自动打包工具，由于一开始使用的是手动打包，每次打一个包都要费好长时间，后来了解到自动打包，就很公司申请了一台电脑，用Jenkins搭建了一个自动打包服务器，然后定时去GitHub拉取代码打包，打包成功后上传蒲公英，然后发邮件通知下载，还不存在老师说的出错了就影响其他人提交的问题，感觉我们的持续集成是在GitHub上，缺失了测试环节。听老师讲完感觉我们做的太简单了，但是老师说的这些服务公司根本就没有，现有的这么简单的东西还是我们自己抽时间搞的，但是我们的主要任务毕竟是开发公司的业务产品，而Jenkins持续集成服务也非我专长，不太可能花太多精力去做这个。这个时候我该怎么办？展开作者回复: 其实，CI 不应该占用那么长时间，在构建脚本里写好打包过程，在 CI 服务器上调用一下就好了。至于 CI 监视器，网上有很多，找一个现成的拿来用就好了。