软件质量之路：日构建[2] - 其它资料

软件质量之路：日构建[2]

来源：信管网 2011年11月22日【所有评论】

　　● 统一代码源

　　其次，保证一个开发团队共享统一的代码源。这时候我们需要使用版本控制工具。共享的代码库同样也是XP的一个基本实践。虽然XP还要求开发人员可以修改他人的代码，但我们并不提倡这种做法，这要求团队成员之间有非常高的默契程度。统一的代码源能够保证所有人的代码都归总到一起，这是日构建的基础。如果没有这一点的保证，每一次的构建我们都不得不把所有人的代码集中起来，这无疑会使构建过程变成灾难。

　　统一代码源能够保证任何一位团队成员获得所有的代码，并以此为基础进行开发。

　　● 集成测试

　　只是把代码编译通过并不能够证明软件可以正常工作，评价软件的标准应该是测试。在日构建中必须要执行集成测试，来保证软件确实是能够工作的。

　　集成测试也是一个同义词相当多的名剩腥税阉莆橹げ馐裕˙VT－Build Verification Tests），因为他们认为这种测试主要的目的是为了验证构建的正确性。有些人把它称为冒烟测试（Smoke Test），因为他们觉得这个测试的目的是运行软件，看它是否会"冒烟"。

　　测试应该全部执行完毕，而不是遇到未被满足的错误就放弃测试过程。测试将形成结果，成功的测试，失败的测试，失败测试的细节。最后的结果将通过某种方式通知给相应的人员，要求他们修改设计或测试（如果是测试本身的问题的话）。

　　集成测试是证明构建成功的关键因素。和构建一样，集成测试也应该是自动化的。

　　日构建的基本工具

　　日构建的工具有很多，但是最基础、最广泛的工具是Ant（http://ant.apache.org）。Ant类似于Make，但是加入了跨平台的特性。在这个目标的驱动下，Ant摒弃了Make工具的给予Shell的缺点，提供了一种使用XML配置文件的构建方式，并定义了一个统一的微核心和强大的扩展机制。这些特点使得Ant很快被人所接受、推广。目前，Ant的最新版本是1.6.0。

<project name="MyProject" default="dist" basedir=".">
    <description>
        simple example build file
    </description>

<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
    
    <tstamp/>
    
    <mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
        description="compile the source " >
    
    <javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
        description="generate the distribution" >
    
    <mkdir dir="${dist}/lib"/>
    
    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean" description="clean up" >
    
    <delete dir="${build}"/>
    <delete dir="${dist}"/>
</target>
</project>

　　以上是一个简单，但已经可以完全说明Ant工作流程的例子，来源于Ant的手册。在这个例子中，先定义了项目的基本信息和构建过程中所需要使用到的属性（1），然后初始化环境（2）（创建时戳和目标目录），在3和4中，对项目进行编译和打包，在5处，提供了清除项目输出的途径。

　　在Ant中，最关键的四个概念就是项目（Project）、目标（Target）、任务（Task）和属性（Property）。这四个概念的定义和调度、配置文件的处理构成了Ant的核心。而具体的任务则作为扩展机制。这种微核心的处理思路在很多成功的软件项目中采用过。

　　本文并没有打算对Ant进行全面的介绍，因此，如果你打算在组织中引入日构建，那么，学会使用Ant是必须的。目前很多的IDE环境都提供了对Ant的支持（例如Eclipse），所以使用Ant是很方便的。

　　原则上，光有Ant就已经可以完成一个日构建过程了，但是还有一些软件提供了更好的封装，使得持续集成变得更加的简单。典型的两个工具是AntHill（ http://www.urbancode.com/projects/anthill/default.jsp）和CruiseControl（ http://cruisecontrol.sourceforge.net/）。前者是一个商业软件，提供了很多优秀的日构建实践。使用起来也很简单。后者是鼎鼎大名的Martin Folwer所在的ThoughtWorks公司开发的，可以免费使用。

　　另一个值得关注的软件是Apcache组织下的Maven项目（ http://maven.apache.org/）。这个项目还很年轻，目前才到1.0的发布版。Maven给自己的定位是项目管理软件，使用项目对象模型（POM）来描述一个项目，进一步的简化构建过程，并统一构建过程所出产的工件。Maven的另一个目标是通过一种实际的工具，来推广优秀的实践。例如开发目录树的组织。

　　日构建的代价

　　虽然日构建有诸多的好处，但是要使用日构建并不是一帆风顺的。最大的问题是如何引入日构建的三项基本实践。前两项相对简单，最难的是建立自动化测试。关于这部分的说明请参考测试驱动开发的相关部分。

　　日构建扩展任务

　　日构建的核心任务是编译、构建、执行测试和发布。除了这些任务之外，还可以微日构建添加扩展任务。

　　生成文档。生成文档有很多的方法，其中最关键的是生成API文档。JavaDoc的概念减弱了传统软件开发中文档的重要性，而把大量的文档嵌入到了代码层面中。除了标准的JavaDoc文档之外，还可以利用第三方的工具生成自定义的文档，例如to-do列表文档。XDoclet就是其中的一个工具。

　　预编译。不少的应用引入了预编译。典型的如AspectJ，作为一个AOP工具，AspectJ的作用是使用特定的代码生成器生成AOP的Java代码，然后再进行编译。将预编译的工作纳入到构建过程，可以简化开发的工作量。典型的还包括一些ORM工具。

　　代码分析。代码分析是软件度量的重要工作。代码分析可以为管理人员提供一个判断代码质量依据（不要把它作为唯一的标准）。代码分析是形式化的，因此可以制作成软件，集成到构建过程中来。例如，判断代码是否符合编码规范，文档和代码的比率，包和类涉及的合理性。

　　测试覆盖分析。测试覆盖分析作为辅助测试的手段是非常重要的。测试代码的复审，最关键的评价测试是否足够（相对），单靠人工完成这项工作太勉强了。所以应该令其自动化，并成为构建过程的一部分。

　　问题跟踪。测试过程中出现的问题应该被纳入到一个问题跟踪系统中，可以通过和问题跟踪系统接口来设计自动化的任务。

　　归档和备份。这是很基本，但也是很重要的功能。每天产生的工件应当进行妥当的归档、备份。

[1] [2]