Continuous integration 持续集成构建配置

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

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

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

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

使用TeamCity、MSBsuild和SVN

---

正在寻找急需的建议。

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

---

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

我们为

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

---

部署配置允许非技术性QA资源在准备测试时部署到测试环境中，并避免了错误修复是否已进入测试环境的混淆。

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

关于资料来源的第一工作组：

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

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

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

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

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

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

另一个构建是纯人工构建，每晚触发一次。它永远不会失败

• 创建API文档
• 使用所有规则进行完整的静态代码分析，并生成总体项目质量的某种指标
• 从以前构建的所有项目生成覆盖率报告（遗憾的是，我们没有强制覆盖率增长）
• 制作各种精美的文档，如Maven site等。大多数情况下，这是为管理层/QA准备的

---

在最近的北美（持续集成和测试会议）上，我们进行了类似的对话，我们分享了我们的经验，并试图制定一个从简单CI到非常成熟的CI和发布系统的路线图

原始会议记录如下。还有一个Flickr。 在urbancode博客上也可以找到

澳大利亚人在布里斯班城市会议上再次讨论了这个话题，并提供了一份报告

---

希望这些资源中的一些有用

我现在正在做这个。我们的构建配置执行以下操作：

建造：

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

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

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

• 标记发布的版本
• 创建它的存档，并将其放在目录中保存
• 检查自上次实时构建以来的所有签入注释，并提取带有票证号的注释。然后使用票据的标题生成初步变更列表。在保存给后代之前，PM会对其进行编辑