每日构建说明

每日构建说明

一、概述

1、目的：

保证及时正确构建版本，保证测试工作的正常进行，从而提高开发和测试的效率。

2、范围：

适用于软件开发过程中的版本构建活动。

3、职责：

开发组长：负责提交开发物物，解决每日构建过程中出现的问题。

测试组长：负责构建版本，执行测试，报告构建结果。

项目经理：负责维护每日构建活动的正常运行。

4、工作程序

● 每日构建是持续进行开发、集成、测试的过程。通过提交版本、构建和测试的不继循环，推进项目前进。

● 通过每日构建，能够直观的看到系统已经完成的功能和没有完成的功能。项目经理需要推动组坚持做好每日构建，不但要督促按时提交任务，还要保证构建的顺利。

● 每次构建的工作流程如下：

1. 开发人员在规定的时间内提交在本地编译通过的源代码到SVN服务器.

2. 构建服务器在指定时间内对SVN进行更新检查,并对其进行编译,发布.

3. 发布服务器将编译好的包进行重新部署.

4. 测试人员每天对新版本进行测试,记录bug到缺陷管理系统.

5. 开发从缺陷管理系统中,获得新的bug,解决bug,修改好的代码提交SVN.

每日构建活动从具备测试条件开始，持续到产品达到发布的要求后结束。整个过程需要遵循以下原则：

缺陷优先：开发人员修复缺陷，再提交新增功能。测试人员优先验证缺陷是否已经修改。

谨慎：为了保证构建的成功和后续测试工作的正常进行，提交代码时应该非常谨慎。

自动构建：为了提高构建效率，最好使用工具或者脚本来进行自动构建的工作。

尽早构建：将比较复杂的集成问题提前暴露，并尽早解决，减少项目风险，便新增功能中找出缺陷，也有利于修改缺陷。

二、每日构建现状

构建系统相关系统及软件

构建平台：cruisecontrol，hudson

构建依赖的软件：ant,staf,checkstyle,pmd，StatSVN

构建相关系统：Crucible，配置库（SVN）

构建系统逻辑图

上图是以cruisecontrol为例，图中的cruisecontrol可以替换成hudson。

部署脚本库是指发布配置模块的脚本的服务器（可选）

源代码库是指发布被测试应用程序源代码以及测试相关源代码的服务器。可以是任何配置库（SVN　CVS…）

定时器设置每天特定时间触发，定时器的功能是 CruiseControl 提供的。

自动编译工具将从源代码库中获取的测试代码和被测试代码进行编译。使用CruiseControl 结合 Ant 作为自动编译工具。

测试自动化框架负责将编译完成的被测试代码和测试代码部署到测试环境中，并调用测试自动化执行工具来执行测试。在测试执行介绍后，框架还需要收集相应的执行日志，并将执行结果和日志交由 CruiseControl 进行发布，以供测试和开发人员参考。测试框架采用了开源的 STAF、STAX(可选)框架。

测试执行工具是指进行测试的各种测试工具，测试工具使用了 JUnit，RFT 等。

测试环境是指运行被测试代码和测试脚本的环境。在实际应用中测试环境既可能是一个简单的Windows 服务器，也可能是由许多不同平台，不同类型的服务器组成的复杂环境。建议使用虚拟机的方式。

测试报表工具是将测试执行结果和日志进行呈现的工具。由于测试过程完全自动进行，只有将测试结果和日志尽可能清晰的展示在测试和开发人员面前，才能充分发挥自动测试的作用。

执行过程：

控制机上安装了 CruiseControl 和 STAF、STAX 框架两套工具。

编译机上安装了编译工具 Ant 以及测试执行工具 Junit。编译机可以和控制机在同一台机器上面。

测试机 1 和测试机 2用来运编译打包好的部署文件，可以根据部署要求增加或减少测试机。

该测试方案的具体执行步骤如下：

1. CruiseControl 服务器在每日指定的时间自动从 CVS 服务器获取最新测试代码，完成后 CruiseControl 服务器启动一个 STAF 任务。

2. 该 STAF 任务从 FTP 服务器下载最新配置登录模块的脚本到本地目录。（可选）

3. STAF 将源代码，测试脚本源代码，以及测试代码分发到编译机上。如果控制机和编译机在一起，这个步骤可选。

4. STAF 在编译机上调用编译工具 Ant 来编译源代码。

5. STAF 将编译出的运行时代码（war）部署到测试机1，2中。

6. STAF 将配置登录模块的脚本发布到测试机1，2中，并分别在测试机上运行该脚本来配置登录模块。（可选）

7. STAF 在编译机上调用 JUnit 来运行测试代码。

8. STAF 将测试结果送回控制机并显示。

三、对现在流程的影响

1. 一周开始,开发要制订一周开发计划,形成Feature list,邮件发给相关人员,测试好根据这个制订测试计划.(数据网管目前是由产品与开发讨论共同制订此计划)

2. 每日早晨:每个人都需要看下构建邮件,看成功还是失败,看是否是自己的代码引起的构建失败.

3. 每日例会,对昨天的总结,今天要做的事情做个简单描述,过程中遇到的问题.

4. 开发同事在平常工作中改动变化不大,主要是更规范了,要求必须写注释!

5. 要求开发同事必须在下班前提交已经编译通过的代码(切记!)

6. 另外每日构建要求开发人员进行单元测试,代码走查等工作.(会在报告中有所体现)

对研发的影响

1. 根据项目组约定好提交代码时间,按点提交在本地编译通过的代码,

2. 代码的变更需要完整的注释,附图为数据网管代码提交时候的注释规范

a) 新功能要与需求对应[需求编号+注释]

b) 修改bug要对应缺陷管理系统的bug编号[BUG编号+注释]

c) 现场提出问题修改代码[现场:BUG编号+注释]

3. 开发人员要求按照代码规范编写代码

4. 开发人员制订每周开发计划,邮件给相关人员

5. 开发人员每天早晨,查看构建邮件,了解构建成功与否,失败是什么原因,及时解决构建失败的问题.

6. 开发人员查看缺陷管理系统,了解自己名下的bug.

对测试的影响

每日构建主要对开发影响不大,主要变动在测试方面.

1. 改变原来测试的模式，从研发送测开始集中力量进行测试，变为从研发开始后完成Feature list中第一个功能点，就开始并行功能测试。目的是为了使系统更充分测试，并增加测试时间。

这是以前的模式,开发完成后,送测,这样测试准备时间很长,执行时间很少,导致前期很轻松,后期很忙,无法对系统进行全面,准确的测试！

2. 增加每日构建后,可以和开发同步进行,保证了测试时间,更保证产品质量有相当提高,更有利于开发出现问题后及时跟踪,更正!

3. 每日构建完成后,后续将会完成使用QTP完成自动化的回归测试.(后续准备)

本文来源：https://www.2haoxitong.net/k/doc/db9244a1c67da26925c52cc58bd63186bceb9222.html