持续集成的价值是什么？对于开发和测试人员又意味着什么呢？

　　1.1 持续集成介绍

　　使用持续集成和测试驱动开发的敏捷实践

　　说到持续集成，我们就不得不提到源代码管理，尤其是互联网得今天源代码得管理至关重要，分之策略和代码合并，代码review都是整个软件生命周期得关键点，那么下面我就对常用得代码管理svn和git进行详细介绍和阐述

　　About Git and Git flow

　　Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是

　　svn://proj/|+-trunk+-branches+-tags

　　这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。第一种方法，使用trunk作为主要的开发目录。一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。按照时间的顺序

　　1.1.0开发完毕，代码冻结

　　2.基于已经冻结的trunk，为release1.0打tag此时的目录结构为svn://proj/ +trunk/ (freeze) +branches/ +tags/ +tag_release_1.0　(copy from trunk)

　　3.2.0开始开发，trunk此时为2.0的开发版

　　4.发现1.0有bug，需要修改，基于1.0的tag做branch此时的目录结构为svn://proj/ +trunk/ ( dev 2.0 ) +branches/ +dev_1.0_bugfix (copy from tag/release_1.0) +tags/ +release_1.0　(copy from trunk)

　　5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发

　　6.在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等

　　7.根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）

　　8.这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

　　第二种方法，在每一个release的branch中进行各自的开发，trunk只做发布使用。这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。

　　1.1.0开发，做dev1.0的branch此时的目录结构svn://proj/ +trunk/ (不担负开发任务 ) +branches/ +dev_1.0 (copy from trunk) +tags/

　　2.1.0开发完成，merge dev1.0到trunk此时的目录结构svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (开发任务结束，freeze) +tags/

　　3.根据trunk做1.0的tag此时的目录结构svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (开发任务结束，freeze) +tags/ +tag_release_1.0 (copy from trunk)

　　4.1.0开发，做dev2.0分支此时的目录结构svn://proj/ +trunk/ +branches/ +dev_1.0 (开发任务结束，freeze) +dev_2.0 （进行2.0开发） +tags/ +tag_release_1.0 (copy from trunk)

　　5.1.0有bug，直接在dev1.0的分支上修复此时的目录结构svn://proj/ +trunk/ +branches/ +dev_1.0 (1.0bugfix) +dev_2.0 （进行2.0开发） +tags/ +tag_release_1.0 (copy from trunk)

　　选择性的进行代码merge

　　这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。这里要注意一下的，第六步进行选择性的merge，是可以当2.0开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版本开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，因为要测试嘛。以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点第一种开发模式（trunk进行主要开发，集中式）：优点：管理简单缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动第二种开发模式（分支进行主要开发，分散式）：优点：各自开发独立，不容易相互影响。缺点：管理复杂，merge的时候很麻烦，容易死人

　　1.2 持续集成概念

　　“持续集成”一词来源与极限编程（Extreme Programming）,作为它的12个实践原则之一出现。ThoughtWorks首席科学家、软件开发领域大事Martin Fowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味置顶每天可能发生多次集成。每次集成都是通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大的减少集成的问题，让团队能够更快的开发内聚的软件。从上面的定义可以看出，一个典型的持续集成周期包括以下几个步骤：

　　1.版本控制服务器上有最新的代码

　　2.持续集成服务器从版本控制服务器下载最新的代码

　　3.等代码完全更新以后，调用自动化编译脚本，进行代码编译

　　4.运行所有的自动化测试（单元测试、接口测试、系统级别的UI自动化测试等）

　　5.将结果写入报告文件中，反馈给团队成员

　　6.如果构建失败，必须尽快修改确保下次构建成功

　　7.产生可执行的软件版本，提供给测试人员进行测试持续集成框架是由代码提交活定时来触发的（项目级别的持续集成可以由开发每次代码提交触发，而产品级别的持续集成可以由定时来触发），每次提交到版本控制服务器上的代码都要经过自动化构建，确保每次的代码变更都不会导致持续集成失败。

　　1.3 持续集成目的和价值

　　持续集成的目的不是减少build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用得更加顺畅。在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。持续集成的价值有：1易于定位错误。某一次集成失败了，说明新加的代码或修改的代码引起了错误，很容易就可以知道谁负责的代码出了问题，可以直接找相关人员来进行讨论，分析。2及早在项目里取得系统级成果。每次集成产生的版本都是一个可用的版本。3改善对进度的控制。每次持续集成报告中可以体现目前项目进度，哪部分需求已实现，哪些还没实现。4改善客户关系。可以非常明确的给演示项目进度（理由如上）5更加充分地测试系统中的各个单元。每日构建和测试相结合带来的好处6能在更短的时间里构建整个系统7有助于项目的开发数据的收集8与其他工具结合的持续代码质量改进。如与checkstyle，PMD、Findbugs等9与测试工具或框架结合的持续测试。如LoadRunner等10便于code review。每个build与前一个build之间有什么改动，针对这些改动可以有效的实现code review

　　1.4 持续集成流程图

　　持续集成（Continuous Integration，CI）是一个长期而又敏捷的过程，在核心的CI可以分为两大类，一类是产品级别的持续集成，产品级别的持续集成在发布日做到日构建。另一类也就是本文需重要描述的项目级别的持续集成。项目级别CI贯穿整个项目周期，从项目的FRD到发布后的跟进。下图是项目级别的持续集成的流程图，主要介绍项目使用CI的流程。

　　CI的介入是从立项的时候开始，前期是沟通和方案的定制，然后就是具体策略的执行，这里需要说明一下，CI不是独立存在的个体，他会与测试范围界定、缺陷分析等紧紧结合。当拿到一个项目时，应该怎么做，在流程图中已经说明了一切，首先是要做项目评估，如果项目适合做CI，然后就可以和项目组沟通，达成一直需指定方案计划和资源评估方案，最后进行具体方案的实施。

　　图中节点说明：

　　项目评估：

　　当我们参与一个项目的时候，需要评估下该项目是否适合做项目级别的持续集成，不是什么项目都可以做持续集成的。根据业界的经验，如何项目周期短，迭代次数少，这类的项目就不适合做持续集成，但还是要根据项目的特点进行评估。

　　沟通：

　　这是非常重要的一点，只有团队达成一致，才能将CI持续下去，我们在达成一直的基础上做约定和计划，如果在沟通的过程中无法达成一致，那么个人建议不要进行CI，当然也要去分析为什么没有达成一致。

　　计划约定与资源评估：

　　在沟通达成一致的基础上做出计划约定和资源评估。

　　持续集成实施：

　　在沟通、计划、约定的基础上我们就可以运用工具和策略对起进行实施，具体的工具和实施在后面的章节会做说明。