下面是小编为大家整理的软件质量之路：日构建,供大家参考。
软件质量之路：日构建
日构建是一项非常基础的软件开发实践，遗憾的是，并没有多少组织真正意识到它的好处。通过本章的讨论，你可以知道日构建对软件开发的意义，了解日构建的基本情况以及如何着手进行日构建。
什么是软件开发的有效管理
在一家全国性银行里，是什么保证了复杂的资金结算的正确性？每天各地网点需要保证账户、资金、票据的平衡，才能关闭业务；这些网点的数据都是不断采集的，每个采集点都要保证账户余额，才能最终在一天内完成一家银行的结算。每天，它都像一台精心设计的机器一样运转。不仅是银行，任何企业都可以。小杂货铺老板也知道每天算账，看看今天是盈是亏。这些行为已经成为工作的一部分，甚至成为一种习惯。
软件开发也是一样。我们必须找到一种方法来衡量日常工作，确保日常工作能够有效地继续，并最终将软件开发的过程变成一个内部过程。这种方法 称为日常构建或持续集成。
为什么需要日构建
日构建和持续集成是类似的，对开放源码熟悉的人应该都知道 Nightly Build 。而持续集成这个词来自 P XP 方法，它的频率可以比日构建更高，可以做到几分钟就进行一次集成，故而由此得名。在本文中，我们只讨论日构建，而要将日构建转换为持续集成是非常容易的。事实上，并没有规定持续集成必须是以分钟为单位进行的，如果你愿意，以一周为单位进行持续集成也是可行的。这样区分的目的是为了更
好的使用日构建或是持续集成技术：至少以天为单位，频率越高，效果则越好。
那么，什么 是日施工呢？我们开发软件的传统流程一般是这样的。我们了解领域问题，然后分配任务，不同的人负责不同的软件组件。开发完成后，把每个人的组件整合起来，形成一个完整的软件。这个想法看起来没有任何问题，但是实际操作起来问题很多。
首先，这种方法适用于开发者工作之间没有交集的情况。这种现象在以前是很常见的，但是现在随着软件规模的扩大和分工合作的深入，开发者之间的相互依赖度越来越高，这种明确的责任划分变得越来越困难。
其次，在软件集成的过程中，经常会出现各种各样的问题，但是很难找出问题出在哪里。公平合理，女人 说合理。每个人的代码都没有问题，组合起来就出现了一大堆问题。
所以日构建就将平时难得一见的集成工作转换成频繁进行的一件工作，从而使得原先如同噩梦般的集成变成了一件简单的工作。这也是很容易理解的，如果集成工作几个月才进行一次，谁能够记起几个月前的细节呢？但是如果集成以天，甚至以分钟为单位进行，排除 g bug 就变成一件很容易的事情了。
日构建范例
现在的时间是下午的 17:00 ，马上就到日构建的时间了。团队里四名程序员中的三位已经将自己的源代码和测试代码提交到了一台名为宙斯的机器上，这台机器将负责对代码进行日构建。在他们提交代码之前，已经通过了本机上的构建，并完成了测试。剩下的一位程序员似乎碰到了麻烦，他的代码出现了一些问题，他现在需要编写更多的测试来完善
测试网。看来时间来不及了，他只能够在明天再做提交了。由于他的代码没有和其他人产生依赖，所以迟些提交也没有关系，不过他在下个工作日的时候必须仔细的将最新的源代码检出到本地，在版本控制工具的帮助下，这项工作是很简单的。
17:10 ，宙斯终于开始了构建的过程。他从代码源中检出最新代码，然后开始编译，构建，并执行了所有的测试，从控制台界面上，日构建的负责人（其 中的一位程序员）似乎看到了有部分的测试没有通过，他对剩下的人说，似乎有麻烦了。测试完成之后，将会从代码中生成所有的 I API 文档，并进行代码分析和测试覆盖率分析，最新测试报告和各种其它的报告都将会发布到 b Web 上。
最后。完成构建的软件和相关的资料已经成功的发布了，时钟指向 17:18 。" " 现在只是项目的早期，到了中后期，至少还需要 0 20 分钟的时间" " ，老鸟程序员告诉没有经验的程序员，并让大家去看看测试结果。一个程序员边嘟囔，边看g log 日志，" " 我在本机都已经测试过了呀，怎么会有错呢。" " 检查结果发现是环境问题，配置文件 被人改动了。看来，集成过程中仍然少不了冲突的问题，只不过，这些问题可以被很快的发现，并很快的得以解决。
以上是一个典型的日构建过程，日构建的过程是完全自动化的，通过预先定义好的指令，机器将按照指令顺序执行完所有的构建步骤。日构建中涉及的步骤是可选的。
日构建的价值
可能有些人认为日构建过于浪费时间，但是实际上，比起最后除错的成本来说，日构建成本是微不足道的。当然，在企业中建立日构建制度确实需要花费不少的时间，但从长远来看，这绝对是值得的。
表面上看，日常建设可以降低最终的调试成本，但这只是日常建设最基本的价值。其实日式建造更关键的作用是引入日式建造的体系。这是什么意思？ “ 日积月累 ” 的思想将会给软件企业的开发流程带来改变: : 在 “ 日积月累 ” 的体系下，开发者的协作会更加频繁，开发进度一目了然，软件的质量也会更加稳定。
软件开发本身就是一项强调沟通和协作的活动。但是在日常的活动中，常常出现阻碍沟通的情况，例如需要沟通的双方不在同一个地理位置、噪声、沟通双方的意愿等等。因此在软件管理中需要提供一种方法，来鼓励人们进行沟通。日构建就是其中的一种方法（但它并不是唯一的方法）。每一次的构建将会涉及到团队中 的所有成员，因此沟通是少不了的，在日构建实践的驱动下，每位开发人员都朝着最终的目的－" " 成功的构建" " 努力。
在 在 n Alistair Cockburn 的敏捷软件开发的第三章中，详细的阐述了团队沟通和协作中的相关问题。例如沟通的实质，影响沟通的各种因素，以及如何克服他们。最后，他还论述了如何促进团队的沟通，来打造一支成功的团队。
在日构建的驱动下，项目的进度将会变得非常的明显。每一天的构建结果将会通过某个渠道发布出来，团队和团队的老板可以看到软件现在的样子，项目的完成情况，出现的问题等等。这些信息构成了软件开 发的基本信息。不但可以清晰地描述出项目进度，也为管理人员安排计划提供了基础数据的支持。有了基本的量化数据，软件开发才不是靠拍脑袋出成果的。
日构建的最后一个价值是提供了整合性。目前软件开发中并没有一种统一的管理软件，未来似乎也很难做到，因为不同的软件组织差异很大。在开发过程中，一些有价值的实
践被加入、集成到日构建的过程中，在日构建的推动下，这些优秀实践很容易成为开发过程的一部分。在文章倡导的另一个优秀实践－测试驱动开发实践，就很容易集成到日构建中来。事实上，软件测试是非常重要的，它已经成为日构建成功的判 别因素。
选择日构建还是持续集成
虽然日构建和持续集成的本质是相同的，但是他们在集成的频率方面的差异也导致了一些管理上的差异：
首先，每日构建设定了明确的工作日目标，团队的目的是让代码通过每日构建。在明确目标的指引下，开发者往往能发挥出高效率。持续集成会使这个频率更小。一旦您的代码被提交到代码库，您的成果将立即得到检验。如果有问题，必须立即排除。否则，要么集成过程无法继续，要么错误的开发人员的邮箱将在集成过程中被警告消息填满。这种做法对团队的要求更高。对于刚刚开始搭建联络日的团队来说，可能有些 着急了。
其次，日常施工有非常明确的分界线。开发工作要么完成，要么不完成，没有第三种状态。
日构建的基础实践
日常构建的基础包括三个实践: : 自动构建、统一代码源和集成测试。
● 自动构建
自动构建的思路是通过脚本语言，而不是通过在 E IDE 环境中点击构建按钮来完成项目的构建过程。日构建需要不断的进行集成的工作，如果手工来完成这项工作，既费时，效果又不好。所以更聪明的做法是把这件工作给自动化。在早
期的 x Unix 环境中，都是采用 e Make 编写相应的脚本来完成构建的过程。随着先进的 IDE 环境的发 展，慢慢的人们就不愿意再编写 e Make 脚本了。可是现在，为了自动构建的目标，我们需要回归到手工编写 e Make 脚本的历史上去。应该说， IDE环境中的构建方式侧重于个人开发，而自动构建则侧重于团队开发
自动构建的目标是用一个简单的命令完成构建过程。
● 统一代码源
其次，保证一个开发团队共享统一的代码源。这时候我们需要使用版本控制工具。共享的代码库同样也是 P XP 的一个基本实践。虽然 P XP 还要求开发人员可以修改他人的代码，但我们并不提倡这种做法，这要求团队成员之间有非常高的默契程度。统一的代码源能够保证所有 人的代码都归总到一起，这是日构建的基础。如果没有这一点的保证，每一次的构建我们都不得不把所有人的代码集中起来，这无疑会使构建过程变成灾难。
统一的代码源可以保证任何一个团队成员都能得到所有的代码，并在此基础上进行开发。
● 集成测试
仅仅编译代码并不能证明软件可以正常工作。评价软件的标准应该是测试。在日常建设中，必须进行集成测试，以确保软件能够真正工作。
集成测试也是一个同义词相当多的名剩 腥税阉 莆橹げ馐裕 ˙VT － Build Verification Tests ），因为他们认为这种测 试主要的目的是为了验证构建的正确性。有些人把它称为冒烟测试（ Smoke Test ），因为他们觉得这个测试的目的是运行软件，看它是否会" " 冒烟" " 。
测试应该全部执行完毕，而不是遇到未被满足的错误就放弃测试过程。测试将形成结果，成功的测试，失败的测试，失败测试的细节。最后的结果将通过某种方式通知给相应的人员，要求他们修改设计或测试（如果是测试本身的问题的话）。
集成测试是证明构建成功的关键因素。和构建一样，集成测试也应该是自动化的。
日构建的基本工具
日构建的工具有很多，但是最基础、最广泛的工具是 Ant（）。t Ant 类似于 Make ，但是加入了跨平台的特性。在这个目标的驱动下，t Ant 摒弃了 e Make 工具的给予 l Shell 的缺点，提供了一种使用 L XML 配置文件的构建方式，并定义了一个统一的微核心和强大的扩展机制。这些特点使得 t Ant 很快被人所接受、推广。目前，t Ant 的最新版本是 1.6.0 。
<project name="MyProject" default="dist" basedir="."> <description> simple example build file </description> <! --
set global properties for this build -- > <property name="src" location="src"/> <property name="build" location="build"/> <property name="dist" location="dist"/> <target name="init"> <! --
Create the time stamp -- > <tstamp/> <! --
Create the build directory structure used by pile -- > <mkdir dir="${build}"/> </target> <target name="pile" depends="init" description="pile the source " > <! --
Compile the java code from ${src} into ${build} -- > <javac srcdir="${src}" destdir="${build}"/> </target> <target
name="di st" depends="pile" description="generate the distribution" > <! --
Create the distribution directory -- > <mkdir dir="${dist}/lib"/> <! --
Put everything in ${build} into the MyProject- -${DSTAMP}.jar ; <jar jar;${dist}/lib/MyProject- -${DSTAMP}.jar" basedir="${b uild}"/> </target> <target name="clean" description="clean up" > <! --
Delete the ${build} and ${dist} directory trees -- > <delete dir="${build}"/> <delete dir="${dist}"/> </target> </project>
以上是一个简单，但已经可以完全说明 t Ant 工作流程的例子，来源于 t Ant 的手册。在这个例子中，先定义了项目的基本信息和构建过程中 所需要使用到的属性（1 1 ），然后初始化环境（2 2 ）（创建时戳和目标目录），在 3 3 和 和 4 4 中，对项目进行编译和打包，在 5 5 处，提供了清除项目输出的途径。
在 在 t Ant 中，最关键的四个概念就是项目（ Project ）、目标（ Target ）、任务（ Task ）和属性（ Property ）。这四个概念的定义和调度、配置文件的处理构成了 t Ant 的核心。而具体的任务则作为扩展机制。这种微核心的处理思路在很多成功的软件项目中采用过。
本文并没有打算对 t Ant 进行全面的介绍，因此，如果你打算在组织中引入日构建，那么，学会使用 t Ant 是必须的。目前很多的 E IDE 环境都提供了对 t Ant 的支持（例如Eclipse ），所以使用 t Ant 是很方便的。
原则上，光有 t Ant 就已经可以完成一个日构建过程了，但是还有一些软件提供了更好的封装，使得持续集成变得更加的简单。典型的两个工具是 AntHill （
）和CruiseControl （
）。前者是一个商业软件，提供了很多优
秀的日构建实践。使用起来也很简单。后者是鼎鼎大名的r Martin Folwer 所在的 s ThoughtWorks 公司开发的，可以免费使用。
另一个值得关注的软件是 e Apcache 组织下的 n Maven 项目（
）。这个项目还很年轻，目前才到 0 1.0 的发布版。
Maven给自己的定位是项目管理软件，使用项目对象模型（ POM ）来描述一个项目，进一步的简化构建过程，并统一构建过程所出产的工件。n Maven 的另一个目标是通过一种实际的工具，来推广优秀的实践。例如开发目录树的组织。
日构建的代价
虽然日构建有诸多的好处，但...
推荐访问:软件质量之路：日构建 之路 构建 质量