持续集成与灰度发布

一、持续集成

   

　　持续集成（Continuous integration，简称CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

　　持续集成的目的与价值：

    持续集成的目的不是减少build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用得更加顺畅。

    在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。

    而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。

　　持续集成的优点：

    1、快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。

    2、防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

　　持续集成的一些原则：

    1.所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。

　　2.开发人员每天至少向版本控制库中提交一次代码。

　　3.开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

　　4.需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

　　5.每次构建都要100%通过。

　　6.每次构建都可以生成可发布的产品。

　　7.修复失败的构建是优先级最高的事情。

二、灰度发布

        

　　互联网产品的发布大多都是做到这里就直接上线，替换了原有的版本，这种跳跃式的发布是非常危险的，如果产品影响面大，对项目成员的压力是非常大的。灰度发布是在发布新版本的时候，先切分部分流量给新版本，稳定了之后再切分所有流量到新版本。这样一旦有问题，马上修改切分的流量就可以，不需要重新发布，减少了发布风险。这种基于ABTest分流的灰度发布方式已经成为很多公司发布的一个必经流程。在灰度发布过程中，产品团队根据用户的反馈及时完善产品相关功能。目前业界一些著名的互联网公司（如google，百度）都是采用这种类似灰度发布的方式。AB Test系统就是可以实现灰度发布的系统。通过ABTest系统可以方便地以各种方式切换流量。

                             

　　在敏捷开发领域，取消专职测试以后，灰度发布就更加重要。一旦新版本出现问题，能够通过我们的ABTest系统马上将所有流量切回稳定的旧版本。这样做的好处是：

　　1、即时生效，无需发布，快速响应。

　　2、可以渐进地调整比例。

　　3、分流的维度丰富多样。

       

 

本文参考：

http://www.51testing.com/html/62/404362-822549.html

http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html