2019-11-08老师，有什么相对权威的DevOps培训可以推荐吗？网上很多，比较难分辨真正好的，能指明个方向也行的，谢谢！作者回复: 你好，又是一个让我比较纠结的问题啊，说实话，要看你自己对于培训的心理预期，如果你现在对于DevOps还属于门外汉的阶段，我觉得参加一个培训建立全局认知，多理解一些案例，是有帮助入门的，但是如果说入门之后，只靠培训就比较困难了，因为你面临的实际问题，并不是培训的主题，培训更多的是一些客观的技能提升，比如某个工具，语言，技能等等，还是要跟高手一起共事和思考才行，如果你们公司在做一些这方面的转型工作，你可以多关注一下参与一下，在解决实际问题的过程中积累经验。
3
2019-11-07对于老师问的三个问题，我们公司可以算是做到了！但对于每一次提交触发集成，想请教下是否意味着每次提交都会触发持续集成流水线？如果是这样，也就是说持续集成是包含持续部署的？因为构建只能运行单元测试，但是大量的自动化还是需要先部署服务的！再就是老师所说的每次提交集成触发这个机制，很想请教下老师，您推荐监控主线分支还是特性分支？或者说有专门的集成分支？如果是主线分支，按照特性分支策略，其实已经做过一轮测试了再提交到主干的，所以我很想知道您落地时思考的工作流程！也就是在实际工作中的整个流程！比如从拉分支，提交代码到远端分支，是否会触发持续集成服务，还是说只有集成到主干才会触发？作者回复: 你好，感谢你的留言，抱歉回复晚了。首先，要区分开持续集成和持续部署，也就是常说的CICD的关系。CI一般意义上来说是研发实践，核心目的是给研发快速的反馈，所以这个阶段最重要的就是运行时间，所以对于一些比较耗时的操作，比如系统集成测试是不会放在这个环节进行的。至于说是否需要部署服务，还真不能一概而论，因为有些项目单元测试也是依赖于环境的！我也见过有的团队会在持续集成过程中跑核心接口测试，其实我觉得不用太过于教条应该有哪些环节，而是根据实际情况，以快速反馈为优先搭建整个流程。
第二个问题，是监控主线分支还是特性分支，这首先要看你们当前的分支策略。原则上如果你采用的是我推荐的分支策略，也就是带特性分支的主干开发分支发布，那么会在两个点来做持续集成，一个是提交特性分支时间点，一个是集成主线的时间点，当然如果你们有在用MR或者PR的机制，那么MR/PR也是一个可选的时间点，但是注意要做一次和主干的合并操作。核心就是两个关注点，一个是特性分支是否正常，另外一个就是特性跟主线集成后是否正常，只要把这两个点检查到就OK，你可以按需选择检查点。
最后无论主干是否有持续集成，都需要一些定期的构建，因为主线上的测试往往依赖于环境，甚至是手工测试的内容，所以并不是只要跑了持续集成就可以的，常见的做法还是按照测试节奏，手工部署环节后验收。 3
2019-11-07赶巧了我是12讲发出来才看的11讲，刚好一起看的，所以难免想起好像在哪儿有一个论调，翻了下笔记，https://www.continuousdeliveryconsulting.com/blog/organisation-pattern-trunk-based-development/，这哥们提到Jez humble在 https://book.douban.com/subject/26702829/ 将TBD称为CI的synonymous
而对于老师的思考题，我的问题在于我好像连老师三连问的第一问好像都举不了手…作者回复: 你好，很多理念，比如TBD，CI，这些都是一以贯之的哈，关于CI的三个测试问题，你可以参考下这篇文章： [https://martinfowler.com/bliki/ContinuousIntegrationCertification.html](https://martinfowler.com/bliki/ContinuousIntegrationCertification.html)
2 3
2019-11-11老师，问一个问题下，您觉得自动化测试能算是运维技能树当中的一环吗？还是应该归测试组的职责？作为运维，需要了解到什么程度的自动化测试的知识呢？只要会配置就好吗？还是也要去了解如何编写测试案例？我们公司现在都是请大学生来做自动化测试这块，进展很慢，我很想帮忙，但是又不知道要怎么切入，值不值得花时间去学习…作者回复: 你好，坦率的说，我不是很建议运维去做自动化测试的事情，因为自动化测试本身受到使用场景的限制，根据不同的业务形态能发挥的价值也不确定，你可以了解一些测试的思路，这对于后续做运维平台或者产品也很有帮助哈，因为测试能够以更加全面的视角来看待问题，而实现者往往只关注一条路径。
1
2019-11-10周六雷涛老师在我们公司做devops培训，果然也问了这3个问题，真的是灵魂拷问啊。作者回复: 哈哈，不知道你回答上了几个问题呢😄
1
2019-11-07ci是一套理念，随着它的推行会催生出工具平台和文化。工具平台的重心在于提高效率，也就是所有可以被自动化的操作最终都由自动化来解决，使得问题可以close，人力可以得到解放。文化则是倒逼着人们制定并执行ci的流程，同时开始切割集成工作，缩小每次集成的力度提高灵活性，规范每次提交的原子性提高版本管理和问题识别的精准度，以及核心流程单元测试的编写close风险。作者回复: 嗯，我觉得很多时候我们都在就事论事，比如ci有问题就谈ci，其实ci也是整个团队能力的体现，需求拆分是否合理，分支策略是否合适，构建速度是否足够快，自动化测试能力有没有，质量门禁的指标和规则是哪些，通知机制是否合理，反馈是否及时，想把ci做好，真不是工具的问题。
1
2019-11-07之前的公司，采用了gitlab+gerrit+jenkins组件了一条CI的流水线，做的也比较简单，每个人创建自己的分支进行提交，触发jenkins进行编译与自动化测试(测试没人写，只进行了简单的编译检查)。然后在gerrit上进行review，通过代码才能进master。现在的公司没有这套流水线，感觉特别low作者回复: 的确，这些也基本上属于研发标配了，有个小问题，你们为什么要结合Gitlab和Gerrit呢，我们公司也有这样的使用的，原因是公司要求统一使用Gitlab，实际上如果看重Gerrit强大的Review能力的话，为什么不直接使用Gerrit管理代码呢，毕竟多套环境不稳定因素也会增多，同步镜像备份都是麻烦事，不知道你们是怎么考量的呢？
1- 2019-11-07有什么好的自动化测试工具推荐下
作者回复: 你好，不知道你具体指哪种测试类型呢，比如常见的单元测试、接口测试、UI测试，到典型的非功能性测试，如性能，兼容性，稳定性，安全性，再到端到端测试，压力测试等等，即便一种测试类型也有多重模式，比如面向接口的，面向契约的都不相同哈。
我推荐你看下专栏特别放送（下），里面有一幅DevOps工具罗盘图，里面罗列的典型的工具哈，如果对某一个具体的工具有问题，也欢迎给我留言，谢谢。 1 1 
2019-11-07请问老师前端项目在ci中的测试有什么好的联系吗作者回复: 你好，这个必须有，我们团队自己就在使用前后端分离的开发模式，对于Vue.js来说单测可以使用Jest和Mocha，覆盖率采用的Istanbul，在以前的演示项目里面也用到过PhantomJS和CasperJS，当然各种Lint工具对于代码风格也很有用，具体看你的使用场景啦。
1
2019-12-05老师，针对于紧急发布执行CI，由于时间紧迫，开发团队会跳过代码检查和自动化测试。理论上应该是不可以的～但是该如何平衡时间呢？作者回复: 你好，我特别能理解你的处境，紧急问题出了，火急火燎的，啥流程也不顾了，这种情况下，我客观来说，真是没办法，就好像火烧到家门口了，除了赶紧跑路还想啥呢？
所以核心问题不是出了这种情况怎么办，而是怎样尽量避免这种情况发生，以及如何优化这些检查的执行效率。说白了，大家觉得可以跳过，潜意识里面还是觉得没用，不重要。
我觉得至少就事论事来说，可以看看类似这样的问题，是否可以加到自动化测试里面来发现，分析下出现的根音，问题驱动改进。下次再有人说可以跳过哦，就得好好想想，以前出现的坑，是否还愿意再掉进去一次哈。
2019-11-23这句话说的很对-------根据 CI 变更，自动识别匹配对应的测试任务也是一个挑战。
老师，对于ci这块一个很现实的问题困扰着我，跟您请教。
对于ci大多数团队都是半路出家，在存在历史包袱的情况下如何践行ci呢，具体点来讲：
比如，我们在逐步建立代码静态扫描的平台和自动化业务的测试，这个如何能够跟代码的提交，版本的变更相衔接呢，如何能够针对变更进行“增量的CI”呢，有什么好的解决方法和实践么？作者回复: 你好，这是一个特别好的问题啊，看来有深入思考过了，先赞一个👍
首先我想说的是，增量CI也好，精准测试也好，自动回归分析也好，这些高级玩法都是建立于一套成熟的CI机制之上的，所以首先要确保CI的稳定，可靠，执行效率和反馈机制。
至于版本变更关联测试，其实是配置管理的副产品，也就是通过将需求，代码，版本管理起来，通过代码匹配需求，需求匹配模块和测试用例，从而实现全链路的追踪，所以单单只是依靠CI是解决不了这个问题的。当然，如果只是为了CI提效，主要得看你们一个完成CI过程的时间分布，如果大量时间在编译阶段，那么就可以考虑增量编译的方式来改进。所以还是目标导向哈，如果不知道当前的问题，那就不太好给出解决方案啦。
2019-11-17《持续交付：发布可靠软件的系统方法》，这节课和这本书里的很多观点不谋而合，不过在我的公司很难做到这点，欠的东西太多，版本发出后各种问题完成版本不可用，项目延期。作者回复: 你好，的确持续集成的理念从诞生到现在其实并没有什么太多的变化，文章里面的三个问题，其实也代表了持续集成实施的三个阶段，可以对照看下看看是什么地方出了问题。
2019-11-07石老师，您好，关于每次提交触发构建中的方式，应该如何选择呢？能否提供下最佳实践参考，谢谢。作者回复: 你好，我想这个问题首先取决于你们当前的业务形态，比如典型的包括APP类型，服务端类型，智能硬件类型和商业软件类型。为什么说跟业务形态有关，这就牵扯到了分支策略和分支模型，提交构建首先要明确监控哪条分支上的提交，在最开始我的建议是如果资源不够充裕或者集成时长普遍超过15分钟的话，可以优先在主干分支上跑起来，再逐步扩展到下游分支。从集成的操作来说，可以先跑一个最小集，如下载代码，构建，然后再逐步拓展到静态检查，自动化测试等，这样循序渐进的来进行。至于工具层面，最典型的就是Jenkins跟版本控制系统打通，你可以在Jenkins中搜索对应系统的插件，大多可以支持，你也可以留言说明你们现在使用的工具，我可以找到一些更详尽的资料给你哈。
1
2019-11-07老师在文章中的"工具是实践的载体，实践是工具的根基，单纯的工具建设仅仅是千里之行的一小步"其实深有感悟，在此基础上简单的扩充一下"方法/理论是实践的载体，实践是工具的根基，单纯的方法/理论建设仅仅是千里之行的一小步"。
落地性和实践性确实非常成问题：可能自己中小企业和大型企业的OPS的工作时间对半吧，期间其实碰过不少企业做自动化，可是2009就普遍使用的SVN其实很多时候都简单的在人工操作。其实人很多时候不愿意走出舒适和适合的环境：企业在某些方面同样如此，只有在被逼迫到不做不行的时候才会去做才会去反思XXX之前提出的好像不错是不是可以考虑一下。
就像这次大会自己为何去听失败案例讲解：其实就感受到很多的不仅仅是存在而且是普遍现象；引发了大量的反思和自己的策划。通过广度去明白/理解深度，从而在实践中修正深度。
其实当我们确定去做的时候有些工作是可以提前做的：这个月就又学习了关于项目管理的，提前做和理解一些事情，这样可能会在真实操作时更好落地。谢谢老师今天的分享，期待下一次的教诲。展开作者回复: 呵呵，我觉得很多时候，文章就是抛砖引玉，而留言区的互动反而更加精彩，因为能看到不用形态、规模、岗位的同学对于同一个问题的不同思考，以及面对的困难，和自己的观点。
虽然目标是确定的，但是实践的路径却有很多条，所以不要迷恋一家之言，有独立思考能力才更加重要，感谢leslie的补充和回复。就像一个心理咨询师，他不会替你解决问题，更多的是帮助你解决问题，企业的外部顾问也是如此，很多时候的确需要一个外部的推动力，或者目标性更强的事情来推动团队的变革。