持续集成构建配置

Question

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

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

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

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

使用 TeamCity、MSBsuild 和 SVN

寻找急需的建议。

Answer 1

我见过的最完整的构建按照给定的顺序做了以下事情。 有两个组，无论失败，每个组中的所有目标都会执行，但如果组中的成员失败，则该组也会失败。 所以我们看到了所有问题。

第一组处理源代码：

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

第二组正在处理生成的代码，前提是第一步成功：

• 运行单元测试
• 运行快速集成测试
• 对源代码进行静态代码分析（大多数 Java 工具都是这样做的），例如检查典型的错误模式（例如Findbugs 对 Java 执行此操作）
• 进行引用检查，例如强制架构分层、允许使用其他类中的某些类类等
• 创建完整的部署包

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

长时间运行的集成测试（每个 2 小时）将每晚运行一次，并且只编译

• 运行
• 长时间运行的测试

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

• 创建 API 文档
• 对所有规则进行完整的静态代码分析，并为整体项目质量生成某种指标 在
• 之前，从所有项目生成生成覆盖率报告（遗憾的是我们没有强制覆盖率增长）
• 生成各种花哨的文档 Maven 站点或 Sonar 报告 等。这大多数时候用于管理/QA。

Answer 2

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

这为我们提供了一些关于每次签到的统计质量的统计数据，用于计划和改善我们的工作习惯。

Answer 3

我们有编译配置

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

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

Answer 4

我们在最近的 CITCON 北美（持续集成和测试会议），我们都分享了我们的经验并尝试整理了从简单 CI 到非常成熟的 CI 和发布系统的路线图。

原始会议记录为 此处。 以及 Flickr 照片流。
清理版本位于Urbancode 博客也是如此。

澳大利亚人在布里斯班 CITCON 上重新讨论了这个话题，并且 pencast 已经发布了

希望其中一些资源很有用。

Answer 5

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

构建：

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

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

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

• 标记已发布的版本
• 创建它的存档，并将其放在一个目录中以保存保存 检查
• 自上次实时构建以来的所有签入评论并提取带有票号的评论。 然后使用工单的标题生成初步变更列表。 这是由总理编辑后保存给后代的。