持续集成成熟度模型

参考原文: 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（报告趋势）

转载于:https://my.oschina.net/u/134516/blog/495563