持续集成构建配置

Question

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

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

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

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

使用TeamCity，MSBsuild和SVN

寻找急需的建议。

Answer 1

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

第一组工作来源：

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

我们已经构建了配置

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

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

Answer 4

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

原始会议记录在这里 。 随着一个Flickr 照片流 。 城市代码博客也提供清理版本 。

澳大利亚人在CITCON布里斯班重新审视了这个主题，并提供了一个可用的Pencast

希望其中一些资源是有用的。

Answer 5

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

建立：

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

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

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

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