持续集成成熟度模型

参考原文: http://my.oschina.net/u/134516/blog/495477

 成熟度模型的级别

1. Base： 在Base这个级别，咱们刚刚跟“模型”沾边，咱们的团队再也不是全部的流程都要手动去操做。

2. Beginner: 团队开始认真采用一些企业持续交付的实践，可是仍是在刚起步的水平

3. Intermediate: 实践已经多少成熟一些，会发布更少的错误，而且更加高效。 对于大多数团队来讲，这个基本的实践可能已经足够了

4. Advanced：团队所作的已经远远超出同行业其余团队，并且效率很是高，可以预防错误的发生。

5. Extreme: 要达到这个级别里的要求，其代价是很是昂贵的，但对某些团队来讲，这是他们的目标。换句话说，大多数组织认为除非疯了才会实现到这个级别，然而另外一少部分则认为不实现到这个级别才是疯了呢。

构建，部署，测试和报告

这几个主题覆盖了端到端的构建生命周期的基本要素，从源代码到生成环境的软件的过程。

构建

  已开发人员为中心的持续集成，其关键在于构建软件的快速反馈。在企业开发中，构建管理和可控的构建流程是很是关键的因素。一个可控的构建流程规范了获取源代码，编译，打包以及存储等一系列步骤。

大多数工程开始的时候是在开发的机器上去进行构建，并无一个规范的流程。这个开发用IDE来构建，而另外一个则用构建脚本。一些极不成熟的团队会用这些构建结果来测试甚至发布到生产环境。这样缺乏控制致使的结果在不少团队迅速显现，他们开始寻找更好的选择。

    咱们的目标应该是：基于提交的构建，有依赖仓库，安全的配置。

    详见：http://my.oschina.net/u/134516/blog/496267

部署

发布是将软件挪到一个可测试，用户能够访问，或者准备发送给客户的地方。对于Web应用来讲，这可能意味着将应用安装在一系列web服务器上，同事更新数据库或者静态存储服务器。对于视频游戏控制端，一次部署应该是将游戏安装到测试机器上，而生产环境的部署还可能涉及到“stamping a gold ISO to deliver to the publisher”（不太懂游戏的发布没法正确翻译出来...）

部署一开始大多数是手动的流程。将构建的地址发送给部署工程师，而后部署工程师将构建结果挪到目标机器，经过执行安装程序完成部署。这样将致使部署过程慢而且部署失败率高。工程师经常被迫在晚上和周末在生产系统和测试系统执行有风险的部署，这个过程当中，系统是不能别其余人用的，然而极可能就有测试正在使用该系统。更糟糕的是，不一样环境的部署可能有不一样的流程，这样很难保证在一个环境的成功部署能够在下一个环境中一样成功。

部署自动化的目标：Test Gated Automation Promotions，Database Deployments，Coordinated SOA/multi-tier deploys.

测试

持续集成和交付长时间来已经某种程度上和自动化测试联系在一块儿。这个在Martin Fowler的开创性文章和Steve McConnell对每日构建和冒烟测试的早期实践描述中被证明。事实上，这主要是咱们想在执行常规构建和部署的时候可以很快提供质量问题的反馈。企业持续交付的范围内,多种类型的自动化测试和手工测试都被考虑到了。

讽刺的是，不少擅长构建和部署的团队，在测试上却很弱。他们执行构建，使其经过一些基本的手动测试，而后就发布出去。应用的某些部分常常被破坏，而新的功能也没能被充分测试。随着团队在测试领域的逐渐成熟，他们能够很快返现问题，提升了生产力和信心。

测试自动化目标：Some Static Analysis（静态分析），Automated Functional Tests run nightly（每晚执行自动化功能测试）

报告

从历史上看，持续集成工具主要关注于报告最近构建的状态。更普遍的观点上来看，报告是企业持续交付的关键因素。企业持续交付的报告涵盖了软件质量和内容信息以及企业持续发布流程的相关指标。

没有报告的团队是盲目的前进。若是没有人能审查结果，那么全部的测试都是无用的。一样，没有被提炼成易理解信息的堆积数据也是没有用的。成熟的团队的报告会愈来愈可视化，会暴露出愈来愈多的有用信息。

报告成熟度的目标：Report Trending（报告趋势）