持续集成构建配置

Question

我被指控在我公司设置CI服务器，我正在寻找一些关于我的项目需要什么构建配置的建议。 作为第一步，我将构建设置为：

提交构建：编译代码并运行单元测试
集成构建：编译代码并运行长时间运行的集成测试

我不确定我还需要什么来完成CI图片。例如，您的商店中有哪些构建配置？

我知道必须有一个步骤来部署我的成功构建，但是我会将部署作为Integration的一部分吗？

使用TeamCity，MSBsuild和SVN

寻找急需的建议。

Answer 1

我见过的最完整的版本按给定顺序执行了以下操作。有两个组，无论失败如何，每个组中的所有目标都会执行，但如果组成员失败，则组将失败。所以我们看到了所有问题。

第一组研究资料来源：

• 清洁工作目录
• 更新到最新来源，从SVN获取所有内容
• 编译资源，rmic等。
• valudate XML资源（至少在Java中有很多，比如部署描述符，样式表等）。
• 执行可用于源的静态代码分析，例如检查空格，编码约定namings，文件名或对源的AST进行的更复杂的检查（如PMD为Java做的那样）。
• 检查其他文件的命名约定，例如我们检查了所有依赖库的名称以包含版本号。

第二组正在处理生成的代码，只有第一步成功：

• 运行单元测试
• 运行快速集成测试
• 为源提供静态代码分析（Java的大多数工具都是这样做的），例如：检查典型的错误模式（如Findbugs为Java做）
• 进行参考检查，例如强制执行体系结构分层，允许使用其他类的某些类等。
• 创建完整的部署包

这是一次又一次触发提交的主要构建。它做了很多，但有一些强大的机器使用几个核心，它约为4分钟500k LOC。如果他们愿意，测试人员可以获得最新的快照构建。

长时间运行的集成测试（每个2小时）每晚运行一次，只进行

• 编译
• 运行长时间运行测试

另一个版本是纯粹的文档构建，每晚触发一次。它永远不会失败。

• 创建API文档
• 使用所有规则进行完整的静态代码分析，并为整体项目质量生成某种指标
• 从之前构建的所有项目中生成覆盖率报告（遗憾的是我们没有强制实施覆盖范围）
• 制作各种花哨的文档，如Maven网站或Sonar report等。大部分时间用于管理/质量保证。

Answer 2

我们在每个CI运行的先前项目中运行的代码覆盖率记录， 发布自动生成的文档和Checkstyle报告。

这给了我们一些关于每个登记计划的统计质量的统计数据，以及改善我们的工作习惯。

Answer 3

我们已经为

构建了配置

• 编译+单元测试+静态分析（在我们的例子中为findbugs）+代码覆盖率（在提交时触发）
• 集成测试（只要有提交就按计划触发）
• 部署测试（手动触发）

部署配置允许非技术QA资源在他们准备测试某些内容时部署到测试环境，并避免混淆错误修复是否已经到达测试环境。

Answer 4

我们在最近的CITCON北美（持续集成和测试会议）上进行了类似的对话，在那里我们分享了我们的经验，并试图整理从简单的CI到非常内置的CI和发布的路线图系统

原始会议记录为here。随着Flickr photostream。 城市代码博客也提供cleaned up version。

澳大利亚人在CITCON布里斯班重温了这个话题，其中pencast可用

希望其中一些资源有用。

Answer 5

我正在研究这个问题。我们的构建配置执行以下操作：

构建

• 编译。
• 测试。
• 将不同的特定于环境的配置值与基本配置合并（这使我们无法使用Staging.config，Test.config等）
• 创建一个名为VERSION.txt的文件，列出构建时间，修订号等。
• 将所有这些内容发布到干净的目录中。然后由teamcity将其作为构建工件。

现在我们有一个可以发布到任何服务器的应用程序，只需将其复制到部署目录，并将相应的配置文件重命名为web.config

我们还有3个配置部署。每次成功构建后，第一个都会部署到开发环境中。这为我们提供了最新代码库的工作版本。第二个部署到手动分段。这将设置为从上一个固定的开发版本进行部署。最后，有一个实时部署配置，然后从上次部署的暂存构建进行部署。这有很多额外的东西：

• 标记发布的版本
• 创建一个存档，将其存放在目录中以便保存
• 查看自上次实时构建以来的所有签到注释，并提取带有票号的内容。然后使用故障单的标题生成初步更改列表。这是由PM编辑的，然后保存给子孙后代。