百度持续交付案例—微信语音分享实录
2019-12-26
来源：百度敏捷教练
Cooder这个平台，或者Gerrit这个平台就做这个工作。
那如果以上四步都通过了，我们还需要做什么？还需要做第五步，就是再次将线上最新的代码，拉到本地。为什么？因为在你刚才做刚才四个步骤的时候，有可能别人已经把它的代码去提交了，这个时候你可能的代码会造成冲突，因为你们的代码都在主干上。
那么同样的过程，第六步、第七步就是要继续做你的Local build、继续做Code review，然后把你的代码Merge到我们的主干上。主干的合入就会触发刚才我们说的持续集成的相关的步骤。比如说会自动要做一级的构建、二级的构建，这是我们持续集成的步骤。
我们刚才讲流水线的时候，其实也讲到了有很多个阶段，尤其在测试这个过程里面，其实还是相对比较复杂的，下面这张图详细去解释这个测试的分级，我们内部叫四级的构建，从L1的L4：
L1级的构建，一般是这种代码级的构建，包括这种代码的静态检查，包括编译，单元测试，以及冒烟测试。
L2级的构建，一般是测模块本身的功能，它对周边的模块采用一些桩或者mock的技术，把依赖模拟掉，来测试模快本身的功能性和接口的正确性。
L3级的构建，基本是在一个相对真的环境里做测试，比如说一个产品要运行起来，可能需要ABCD多个模块共同作用，那我们L3级的测试就是在我们叫沙盒的测试环境，完成这个测试工作。它所连接的系统都是真实的系统，在这里会做功能性的测试和端到端的测试，相关的集成测试，以及一些异常和压力相关的测试。
L4级的构建，是在Pre-Online准生产环境，是上线之前的最后一次验证机会，除了你这个模块是新的，是新部署的之外，其他的模块都是保证跟线上的环境完全相同。这样话你测出来的问题，一定是你这个模块的问题，达不到上线标准。所以说在Pre-Online这个测试里面的话我会建议去做一些用户场景类的测试，我们叫UST，以及一些运维演练等。
刚才说的是我们整体方案的部分，实际在推广的时候我们还要建立一个虚拟的组织去推广持续集成和持续交付模式。我们也建立了一个多层的组织模式：
最顶层我们叫CI Core，是一个持续集成的核心的领导小组，那这个组的话就是负责我们CI的整体的规划，负责对整体效果和进展的一个把控，以及他对这种技术难点难题问题进行协调和解决。
在这个CI Core旁边的话，就是我们Sponsors，我们一定要把相关的RD、QA，相关的经理和总监拉进来，获得在资源和决策上的一个支持。
第三层我们叫Mentor层，就是导师的这个层次，它是提供整个过程的技术指导，它会为我们各个QA接口人提出的问题，提供一个解决的机制。如果说我们具体执行的时候，相关接口人有问题，那么首先是由Mentor这个层来负责指导和解决的。那如果Mentor解决不了，再去向上去传递到我们CI Core这个Team。
最后一层是我们QA的接口人，每个团队有自己的接口人负责具体去推行，持续集成和持续交付的工作，比如建立相关的job去做自动化的脚本，比如去做部署的改造等等，这些由我们QA接口人去做统一的实施。
我们说持续集成也好，持续交付也好，为了得到一个比较好的效果，一定要强调团队的习惯。我们在试点团队，采取了一个叫Build cop的机制，我们叫构建警察的一个机制。相当于通过这种机制去保证你相关的工作能够真正落实到位，比如说最基础的，我如果这个代码提交之后引起的主干上相关job失败，那我们要把这种红灯的问题作为第一优先级的问题去解决。谁去监督呢？我们就
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
