概要

通过每日构建或者持续集成，项目组可以及早发现集成问题。现在它的意义已经为众多的开发团队所认识。一些重要问题的处理，如构建版本的分类和提升、与自动测试系统和项目或缺陷管理系统的集成，能够使项目组从中得到更多的收益。本文将对这些方面进行描述，并介绍作为开放源代码构建自动化和管理工具的 luntbuild 在以上方面的努力。

1 ．每日构建和存在的问题

1 ． 1 每日构建的一般机理

 

如今，每日构建已经在许多项目中得到广泛的应用，以便及早发现集成问题。本文描述了建立每日构建系统中的一些想法，并 介绍开放源代码的每日构建工具 luntbuild （ http://luntbuild.sf.net ）。

 

每日构建的机理很简单：

1．  定期（如每夜）检查源代码库

2．  如果源代码库中发生改变将触发构建和后续的冒烟测试

3．  给源代码库的当前构建作一个标签，以便将来可以提取当前构建进行重新构建

4．  给相应开发人员发送报告构建情况的 email 。

 

XP 方法的持续集成风格也具有与每日构建相同的机理

 

1 ． 2 每日构建存在的问题

如果下列方面能够得到妥善处理，项目组可以从每日构建系统中获得除尽早发现集成问题之外的好处。

 

1 ．为了给并行开发提供最大程度的构建支持，构建系统应该可以将源代码库中来自不同分支或有不同标签的模块组合起来进行构建。这一点对于大项目的开发尤其重要。

 

2 ．历史构建应该能够进行很好的管理。在项目开发尤其是持续集成过程中会产生大量的构建版本，因此，应该能够将他们加以分类以确定一些重要的构建。实现的方法有两个：第一个方法是将一个已经存在的低级构建版本（如通过每日构建产生的一个版本）提升进高级构建类（如测试构建类）。由于分类是在构建完成之后进行的，这种方法被称为后构建标识。第二个方法是直接在指定的类中构建。由于构建类是在构建之前就确定了，这种方法被称为前构建标识。除了分类，系统还应该能查找或删除历史构建。系统可以很方便地找到指定版本、日期、状态等的构建，这就能够在大量的历史构建中搜寻而快速地找到指定的构建。通过删除不重要的历史构建，可以节省存储空间。

 

3 ．当开发大项目时，需要构建记录不仅应该包含最终的分发包，还应该包含一些中间文件或是调试版本文件。因此，构建系统除了替项目组对源代码库进行集成校验外，还提供近期的开发基准或是调试环境。这样，将来可以很方便地通过发出一个命令实现下载特定构建的相关文件并更新开发环境。

 

4 ．当控制访问不同的项目或者是系统的构建或功能时，特别是系统由多个项目构成或是可以被客户下载的等情况，需要使用访问控制机制进行访问控制。

 

5 ．每日构建系统必须能够与项目管理、缺陷跟踪系统建立连接，这样才能方便地建立并保持构建和 bug/feature 之间的关系。例如，某开发人员提交一个 bug 给缺陷管理系统申明该 bug 将在下一个构建中改正，当下次构建完成之后构建管理系统将通知缺陷管理系统刚刚完成构建的版本号，从而缺陷跟踪系统能够知道该开发人员刚刚提交的 bug 在哪个版本中被提交。并且，当发布一个特定的版本时，构建系统可以与缺陷管理系统连接以获得本版本处于不同状态的的 bug/feature 列表和描述，并写入 release notes 中。

 

6 ．每日构建系统必须可以与自动测试系统连接以便在构建完成后除单元测试外的进一步测试。例如，构建系统在生成一个新的构建版本之后将通知自动测试系统，接到通知后，测试系统将下载新的构建版本，将其安装并进行项目跟踪系统所要求的冒烟测试等。

 

实现以上提到的每日构建系统的各个功能并不象安装一个每日构建系统那么容易。在研究了已有的工具之后，我打算开发一个全新的自动构建工具—— luntbuild ，它可以逐步实现上述功能。当前发布的 1.0.2 版本除了具有每日构建系统或持续集成工具的基本功能之外，还可以实现上述的 1 、 2 、 3 功能。下文将介绍 luntbuild ，解释它在这些方面的功能。

2 ． Luntbuild 如何解决上述问题

Luntbuild 不仅仅是一个每日构建和持续集成工具，而是一个自动构建和管理的系统。它基于 apache ant ，需要存在一个 ant build 脚本。而通过提供一个 ant 脚本封装， ant 脚本的编写会变得十分容易。在用户手册中详细说明了具体步骤。

 

2.1 对并行开发提供构建支持

 

Luntbuild 利用项目、视图、模块和计划的概念来自动化和管理构建。项目表示实际的项目以及对应的源代码库。模块表示一组具有版本号的目录以及文件，通常是一个特定分支上或者由特定标签标识的一个源代码目录路径。视图包含若干模块，而项目又包含若干视图。下面举例对此进行说明：

在 luntbuild 中配置一个 cvs 项目“ footbar ”，假定 footbar 包含“ src ”和“ web ”两个目录，“ src ”包含功能源代码而“ web ”包含 web 界面的 html 文件。我们首先创建一个由主分支上的“ src ”和“ web ”模块组成的“ development ”视图，该视图计划每晚构建。开发顺利进行，某日发布了“ foobar-1.0 build123 ”并出售给客户。后来，客户反馈的 bug 与“ src ”目录中代码有关。为了解决这些 bug ，我们在源代码管理系统中为“ src ”目录创建“ 1_0_bugfix ”分支，同时，在 luntbuild 的“ footbar ”项目下创建“ foobar1.0-bugfix ”视图，配置两个模块：“ 1_0_bugfix ”分支上的“ src ”模块，和“ foobar-1_0-build123 ”标签上的“ web ”模块。该视图的构建计划仍然是每天晚上。这样，新功能和改正 bug 的开发工作有单独的视图，并且可以分别按计划进行每日构建。

 

2.2 对历史构建管理的支持

 

在 luntbuild 中，计划不仅用于实现自动构建，还用于实现构建分类。计划被创建之后，可以与特定的视图相关联。这种视图 - 计划对被称为“构建计划”或“构建分类”。为了支持多个构建分类，一个视图可以与多个计划相关联。例如，你可以给开发视图关联三个计划：“每小时”、“每晚”和“发布构建”。“每小时”和“每晚”计划将自动被触发，而“发布构建”计划只能手动触发。为了提高构建速度，我们将“每小时”计划配置为增量构建；为了避免源代码库中的标签过多，我们将“每小时”计划的策略选为“不设标签”。“每小时”计划主要为“持续集成”而设置，这样，可以保证源代码库的一致性。为了提高可靠性，我们将“每晚”计划配置为干净构建；为了使所有的夜晚构建可再现，我们将“每晚”计划的策略选为“在构建成功时进行标签”。“每晚”计划为“更新开发环境”而设置，这将用于更新开发人员的开发环境。“发布构建”计划为维护所有已经发布出去的构建而设置，该构建类中的版本可以是手工触发该类中的构建而生成（即构建前标识），或者是采用构建后标识方法将其他构建类（如每晚构建类中的经过测试过的版本）提升到本类中。

 

除了构建分类和提升， luntbuild 还可以严格或不严格匹配地查找某个版本号的构建，查找指定时间范围、状态或特定构建类中的构建。可以删除查找结果或是特定的构建版本。这样，就可以很方便地执行某些操作比如查找失败的历史构建并删除之。

而且对于某个特定的构建版本，可以删除它下面的文件，或者上传新的文件。从而达到为某个特定的构建版本打补丁的目的。

 

2.3 对设置最新开发环境的支持

 

在 luntbuild 中，特定构建版本所发布的文件是由用户提供的构建脚本决定的， luntbuild 仅仅提供一个发布文件的根目录。所以您可以自由选择要在 luntbuild 中发布的文件。对于大项目来说，如果最新的开发环境包（如调试版本文件等）可以与最终分发包一起发布，开发人员就不需要花很长的时间来编译其他开发人员的代码以更新环境，这将带来极大的便利。

 

2.4 正在开发中的功能

 

所有的单体测试或冒烟测试应在构建脚本中进行， luntbuild 捕获脚本运行的输出结果，并最终发送给为失败视图负责的开发人员（邮件策略是可以配置的，你可以选择每次构建都发送邮件或是不发送邮件）。将来， luntbuild 会以图形的方式显示测试结果，这会比用原始的日志文件表示得更加清楚。

 

目前， luntbuild 尚未实现访问控制。当在开放环境中使用 luntbuild 时，访问控制功能具有重要的意义，因此，现在正在设计这个功能，在日后发布的版本中将会实现。

 

Luntbuild 尚不能与第三方项目管理 / 缺陷跟踪系统或是自动测试系统连接。这项功能将在日后发布的版本中实现。第一步是提供 web-service 类 API ，使其他系统可以方便地访问 luntbuild 构建信息。