1.2 CI的特征

1.2   CI的特征

既然我们已经看到了一个例子，接下来就可以讨论CI的特征了。CI需要具备的特征只有4项：

与版本控制系统的连接。
构建脚本。
某种类型的反馈机制（如电子邮件）。
集成源代码变更的过程（手工或CI服务器）。

这些主要的行为是实现有效的CI系统的关键。当自动化的脚本在每次版本控制系统发生变更后都会运行之后，您就可以为CI系统添加更多的特征。

通过进行自动化的、持续的数据库集成、测试、审查、部署和反馈，您的CI系统就能够减少项目中常见的风险，使大家对项目更有信心，沟通也更好。某些特征依赖于另一些特征，例如，自动化测试依赖于源代码编译。
这个可重复的过程有助于在整个开发生命周期中减少风险。接下来将详细描述这些子过程。

源代码编译

持续的源代码编译是CI系统中最基本、最常见的特征之一。实际上因为它太常见了，以至于成为了CI的代名词。编译指的是根据人们可读的源代码生成可执行代码。但是，CI不仅仅是源代码编译，随着动态语言（Python、PHP、Ruby等）的兴起，编译在这些环境下稍有不同。虽然在使用动态语言时不会生成二进制代码，但是很多语言都提供了进行严格检查的功能，您可以认为这就是这些动态语言环境中的编译。除了这一点细微的差别之外，动态语言环境仍能从CI构建的其他活动中受益。

集成按钮

集成按钮（参见图1-4）是全部功能和自动化集成构建的可视化表现，它使得构建成为一蹴而就的事情。它包含了许多过程，以确保软件按照预期设想工作。您可以统计、重新生成数据库和测试数据、运行测试、审查、部署并提供反馈。将构建自动化，您可以按下一个按钮就执行许多过程。

数据库集成

一些人认为源代码集成和数据库集成是完全独立的两个过程，它们总是由不同的小组来完成。这很不幸，因为数据库（如果您在项目中用到的话）是软件应用的一个部分。利用CI系统，您可以确保利用单一的来源集成数据库，即版本控制库。

图1-5展示了在CI系统的构建过程中进行持续的数据库集成。我们将数据库源代码，即数据库定义语言（DDL）脚本、数据库操作语言（DML）脚本、存储过程定义、分区等，存放在系统中，像其他源代码一样。例如，当项目成员（开发人员或DBA）修改了数据库脚本并提交到版本控制系统时，集成源代码的构建脚本将重建数据库和数据，作为集成构建过程的一部分。

代码清单1-6展示了如何利用Ant的sql任务删除和创建MySQL数据库。您在重建数据库和测试数据时要做的事可能更多。这个例子中许多硬编码的值只是为了展示的目的。

代码清单1-6   MySQL和Ant

<target name="db:create-database ?
<sql driver="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/"
userid="root"
password="sa"
classpathref="db.lib.path"
delimiter=";">
<fileset file="${database.dir}/drop-database.sql"/>
<fileset file="${database.dir}/create-database.sql "/>
</sql>
</target>

我们将在第5章中展示数据库集成的例子、方法和好处。

测试

许多人认为，没有自动化的、持续的测试的CI不能算作是CI。我们非常同意。没有自动化的测试，开发者或其他项目风险承担者对软件的变更很难有信心。在使用CI系统的项目中，大部分开发会使用JUnit、NUnit或其他xUnit框架等单元测试工具来进行测试。而且，您可以通过CI运行不同类型的测试，加快构建的过程。这些分类可以包括单元测试、组件测试、系统测试、负载/性能测试、安全测试和其他测试。第6章更详细地讨论了这些测试。图1-6展示了CuiseControl这样的CI服务器所产生的JUnit报告，它是集成构建的一部分工作。

代码清单1-7展示了一个例子，它是运行一组JUnit测试并生成图1-6中的报告的Ant任务。
代码清单1-7   Ant和JUnit

<?xml version="1.0"encoding="iso-8859-1"?>
<target name="run-tests">
<mkdir dir="${logs.junit.dir}"/>
<junit fork="yes"haltonfailure="true"dir="${basedir}"
printsummary="yes">
<classpath refid="test.class.path"/>
<classpath refid="project.class.path"/>
<formatter type="plain"usefile="true"/>
<formatter type="xml"usefile="true"/>
<batchtest fork="yes"todir="${logs.junit.dir}">
<fileset dir="${test.unit.dir}">
<patternset refid="test.sources.pattern"/>
</fileset>
</batchtest>
</junit>
<mkdir dir="${reports.junit.dir}"/>
<junitreport todir="${reports.junit.dir}">
<fileset dir="${logs.junit.dir}">
<include name="TEST-*.xml"/>
<include name="TEST-*.txt"/>
</fileset>
<report format="frames"todir="${reports.junit.dir}"/>
</junitreport>
</target>
</project>  

审查

自动化的代码审查（例如静态和动态分析）可以通过强制遵守规则来增加软件的品质。例如项目可以有一项规则，规定任何一个类的非注释代码行不能超过300行。您可以利用CI系统来对代码自动进行这些规则的检查。我们将在第7章讨论并展示各种工具和技术。

图1-7中的软件审查报告是用Checkstyle生成的，它对Java代码进行审查。利用这样的报告您可以持续监控编码
标准和品质方面的测量指标。

代码清单1-8展示了在Ant中利用Checkstyle静态代码分析工具的一个例子。这个例子生成了图1-7中的报告。
代码清单1-8   在Ant中使用Checkstyle的例子

<target name="run-inspections">
<taskdef resource="checkstyletask.properties"
classpath="${checkstyle.jar}"/>
<checkstyle config ="${basedir}/checkstyle-rules.xml"
failOnViolation ="false">
<formatter toFile ="${checkstyle.data.file}"type="xml"/>
<fileset dir ="${src.dir}"includes="**/*.java"/>
</checkstyle>
<xslt taskname="checkstyle"
in="${checkstyle.data.file}"
out="${checkstyle.report.file}"
style="${checkstyle.xsl.file}"/>
</target>

部署

许多过程都与“部署”有关。实际上，本节中讨论的大部分其他过程都是部署过程的一部分。持续部署让您在任何时候都可以拿出能工作的、可部署的软件。这意味着CI系统的主要目标是生成一组包含最新代码变更的软件工件，提供给测试环境进行测试。

要做的事情包括从版本控制库中签出源代码文件、进行构建、成功执行所有测试和审查、为发布版做上标签、准备好部署文件。

CI甚至可以将文件自动部署或安装到相应的环境中去，如图1-8所示。而且，部署应该包括对部署中所做的变更进行回滚的能力。请注意，您可能在开发（例如，在图1-8中使用了Jetty）和集成测试环境（Tomcat）中使用的操作环境有所不同。不论怎样，这些环境中执行的是同样的构建脚本，只有参数稍有不同。我们将在第8章中讨论这些策略。

<target name="deploy">
<cargo containerId="tomcat5x"action="start"
wait="false"id="${tomcat-refid}">
<zipurlinstaller installurl="${tomcat-installer-url}"/>
<configuration type="standalone"home="${tomcatdir}">
<property name="cargo.remote.username"value="admin"/>
<property name="cargo.remote.password"value=""/>
<deployable type="war"file="${wardir}/${warfile}"/>
</configuration>
</cargo>
</target>

文档与反馈

许多开发者深信文档是属于源代码的，实际上，清楚、简洁的代码和选择得当的类名、变量名和方法名就是最好的文档。CI系统可以在不增加麻烦的情况下提供文档所带来的好处。您可以利用Maven、Javadoc或NDoc这样的工具来生成文档。而且，有许多的工具可以生成类图和其他信息，它们都基于您提交到版本控制库中的源代码。您可以选择定期生成文档，而不是持续生成。

一个好的CI系统的关键特征就是“速度”。CI系统的本质是及时向开发者和项目风险承担者提供反馈信息。很容易在CI系统中加上许多东西（出于完整性的考虑），使得完成一次CI循环需要太多的时间。在这种情况下，必须在CI过程的广度和深度以及快速提供结果的能力之间进行折衷。这一点在使用持续测试时尤其重要。我们将在第4章和第6章中讨论创建快速的构建过程所需的技术。