百度持续交付案例—微信语音分享实录
2019-12-26
来源：百度敏捷教练
个叫Build Cloud的一个平台，就是我们做云编译的这么一个平台。它其实为了提升我们编译的效率，通过这种并发式的编译让你的编译速度有一个很大的提升。再后面是Jenkins平台，它是作为我们后端任务调度的一个平台。可能大家都会用Jenkins去做一些CI的任务，那在这里Jenkins平台是偏后台的一个应用，而前台可以通过我们AGILE平台统一做调度。
那最下面一层是我们跟运维相关的一些平台了：
首先是我们叫BCEDeploy的平台，它是一个负责打包的平台。我们希望通过这种打包平台要把这个打包过程做到标准化，要做一个全量包，并且这个全量包一定是要自包含的，这样的话，去降低我们这个运维的复杂度。
然后是我们这个叫Archer的平台，它是负责部署的平台。就像百度数十万台机器，很多都是通过Archer平台做部署的，只要你满足相关的规范做相应的配置，那么Archer这个工具就会把你的这种全量包部署在我们成千上万的服务器上。
最后还有一个叫Noah的平台，这个是我们的监控平台，提供物理层的、应用层的和业务层的相关监控。
所以总结来看，就是我们刚才讲的三个层次。第一个层次是交付流水线，流水线的编排，流水线的协同。第二层是各层自动化能力的注入，包括自动化测试、自动化部署这些能力的注入。第三层是工具链的支撑，那么通过这个三个层次，去完成了我们整个持续交付的过程。那最终达到一个什么样的效果呢？这个效果就是说你去提交了一行代码，到你的整个持续交付平台里面去，然后这个代码会被从各个角度、通过各种方式被测试，如果它能够闯关成功，就会被一键式的发布到我们的各种环境，甚至一键式的上线。它能够使我们一天能够完成多次的上线、多次的部署，达到这么一个效果。
刚才我们介绍了整个持续交付过程的一些效果，现在我们看一下细节的部分。我给大家发的这张图，就是讲我们做的工作，其实是阶梯式、渐进去做的。首先我们先做的持续集成，达到一定效果后，再去转向持续交付。
持续集成里边有几个关键的实践：
第一个是主干开发、分支发布。
第二个是说我们在做分级的构建模型和分级的自动化测试。
第三个是我们通过一些习惯的养成，去保障我们持续集成的效果。
第四个是我们要用一个量化的方式做度量，提升我们整个持续集成的效果。
我分别给大家做一个详细解释：
首先第一是主干开发、分支发布的这个模式：那这里面其实今天我也不用介绍太多，其实很多公司都在用这个模式，包括google，包括facebook，基本都是一个单主干开发这么一个模式。
其实给我们带来很多收益，比如说我们不需要去频繁的创建很多的分支，不需要频繁的去合并做分支的代码，也不需要去经常同步分支代码和主干，也不需要频繁的多个分支之间做这种切换。
所以说主干开发其实给我们持续集成的效果上带来很多优势。但是我们为了做好主干开发其实有一些关键点要去遵守。下面个图介绍了我们的Check-in Dance，就是开发人员代码提交的一个方法。
首先要从主干将构建成功的最新版本代码check out到本地。
然后第二步，你要在本地做你自己的编码开发。
第三步是要在本地去做这种本地的构建，本地的测试。因为我们要在本地充分验证过的代码，才能够去提交到主干。所以我们一定要保障这种主干的这种可用性，所以我们要在本地去做充分的这种Local build测试。
第四步是我们要发起一个CR，就是我们说的Code Review。刚才也讲到我们有的
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
