tfs - 您在构建自动化期间做了哪些很酷且有趣的事情？

Question

我只是想看看其他人在构建自动化过程中在做什么，而不是通常的编译、构建、运行测试等任务，这些任务可能对其他人考虑和研究有帮助和启发，例如：

生成代码文档
使用代码指标来衡量构建质量，如果违反了既定指标，则构建失败。

score 43 · Accepted Answer

将可执行文件发送到http://virustotal.com以对所有主要的反病毒引擎进行病毒扫描。

并不是说我们认为我们的前任包含病毒，但有时您会得到误报，并且您不希望它成为发现它的客户。8-)

score 21 · Accepted Answer

21

我们有一个推特账户，所以我们可以随时随地查看它的状态

于 2009-05-29T12:11:08.380 回答

score 20 · Accepted Answer

20

我们有一个 Staples 简易按钮，我们已经连接了该按钮以在按下时触发构建。

于 2009-05-29T12:56:42.967 回答

score 16 · Accepted Answer

16

为可能散布在代码周围的任何 TODO/FIXME 等创建报告。

于 2009-05-29T12:33:43.200 回答

score 15 · Accepted Answer

以下是我已经做过、正在做或计划做的一些事情：

更新交通信号灯（使用 X10 小工具）以指示构建状态（绿色=良好，黄色=正在建设，红色=哎呀！）。
生成代码文档，然后使用文档更新项目 wiki。
其他项目 wiki 更新，例如发布当前版本号、提供下载链接等。
部署到（并在必要时回滚）进行手动测试的测试服务器。我通常使用 VMWare 完成此操作，因此“部署”实际上是创建一个新的 VM 实例。
自动将“待构建”的工单移至 QA 进行测试。
为失败的测试、失败的构建和编译器警告创建缺陷报告。
在版本控制中标记构建（也应用版本信息）。
在 Y 天内 X 次或更多次失败的构建后安排审查。（例如，如果一周内发生了三个失败，我们需要开会弄清楚发生了什么）
安排一个“比萨和啤酒”派对，确保没有错误的几周。
播放响亮的“ca-ching”！每当我们知道将导致新销售的功能完成时，都会通过 PA 系统发出声音。在我以前的公司，我们的销售团队喜欢这个无用的功能 :)。

score 12 · Accepted Answer

12

从failblog.com 中拉出一个随机图像以附加到“构建失败”电子邮件。

于 2009-07-16T01:55:11.377 回答

score 7 · Accepted Answer

自动推进您的问题工作流程。

我们为我们的 Bamboo CI 服务器编写了一个自定义插件，它收集与构建相关的所有 JIRA 问题（由 svn commit 评论确定）并检查它们在 JIRA 中的状态。

一旦构建成功（并将应用程序部署到正在运行的服务器），“等待构建”工作流阶段中的任何问题都会自动推进到“已构建并可用于测试”阶段，这会触发一封电子邮件发送到分配给该问题的测试人员。

这意味着我们的测试人员不会在开发人员签入代码时收到问题通知电子邮件，而是当修复程序在服务器上实时运行并且测试人员实际上可以对其进行处理时。

score 6 · Accepted Answer

6

直接部署网站以测试部署服务器。

于 2009-05-29T12:14:17.577 回答

score 4 · Accepted Answer

我们对我们生成的所有二进制文件应用数字签名。构建脚本会自动执行此操作。

score 4 · Accepted Answer

一些东西。

将 pdb 上传到符号/源服务器 <- 对于调试 winqual 故障转储非常有用
对通过 CC.NET部署到VM中的安装程序运行测试
创建用于通过CC.NET进行测试的基础 VM，并将其部署到所有 QA
获取该 VM 映像的副本并使用EggPlant执行自动化 UI 测试

score 3 · Accepted Answer

3

替换 SVG 初始屏幕中的版本号，然后在 Inkscape 中呈现它。

于 2009-05-29T14:01:33.693 回答

score 2 · Accepted Answer

2

我们构建 BizTalk 2006 项目 :)

于 2009-06-07T15:10:26.437 回答

score 2 · Accepted Answer

我们针对我们最新的公开版本进行二进制兼容性分析（使用反射），以确保我们不会意外引入二进制破坏性更改。每当我们被迫进行重大更改时，我们都会将特定的 api 添加到“已接受的重大更改”列表中，以便下一个构建可以跳过测试。到了发布时间时，我们会列出新版本中出现问题的 API 的完整列表。

score 2 · Accepted Answer

我参与过的各种项目都有大型的公开展示，展示了谁最后签入以及谁破坏了构建。我们使用Build-o-matic完成了这项工作，我编写了Team Piazza来为 Team City构建显示相同的信息。

score 2 · Accepted Answer

我们有一个 Web 应用程序并进行了性能测试，并将 HTML/CSS 验证放入测试脚本中。

score 2 · Accepted Answer

托管代码：

使用一致的版本更新所有 AssemblyInfo 文件
运行 StyleCop 和 FxCop 并检查代码是否美观且表现良好！

本机代码：

在二进制文件中运行depends.exe并检查调试运行时是否没有依赖项已经悄悄进入 - 经常发生
使用 manifest.exe 转储清单文件并检查调试依赖项 - 这些东西无处不在！
使用 SWIG 为 C++ 代码生成 python 绑定

score 2 · Accepted Answer

对于 Java 开发，我们使用：

JUnit 由 Cobertura 补充（Cobertura 识别代码的哪些部分缺少测试覆盖）
Find Bugs - 搜索代码以查找错误和漏洞的工具
Hudson 工具（参见 hudson.dev.java.net [我还不能发布超链接！]），它管理软件的构建和测试。它有一个像 AoP 的（上图）红绿灯的特性——蓝色成功构建并且所有单元测试都通过，黄色成功构建并且一些单元测试失败，红色构建失败。

哈德逊也

通过 SVN、Continuus 等插件管理软件构建
维护所有构建的历史记录 - 允许我们的 Junit 测试和 Find Bugs 结果显示在趋势图中
每当构建导致状态发生变化（例如，蓝色到黄色，红色到蓝色）时，向所有相关方发送电子邮件
所有信息都显示在一个简单的内部网页中

score 1 · Accepted Answer

1

我们有一个Nabaztag/tag显示构建服务器上是否发生任何错误。

于 2009-06-16T07:36:05.550 回答

score 1 · Accepted Answer

我没有在这里阅读超过一半的答案，但我希望其中一些是“新的”：

安装和升级旧版本以检查新安装的文件差异（测试我们的部署升级配置）
将我们的核心应用程序和外部系统适配器部署到自定义 Jboss（包含在项目/版本中），启动它并运行 SoapUI 测试套件以验证端到端功能（也是我们部署自动化的额外测试）
将增量脚本应用于以前的数据库版本，然后与新安装进行结构比较，以便在升级期间创建新表、列等
在 Confluence 中发布我们的发布文档（我们基本上每晚都运行完整的发布脚本），作为下一个来自主干的发布的预览

score 1 · Accepted Answer

以下是我在持续集成中通常拥有的一些东西：

计算代码指标和性能统计数据（在执行测试时由我们的框架捕获；
运行执行某些开发指南的代码质量测试（即：类命名、不变性、允许的引用）；
更新从代码生成的在线文档；
将安装包（WiX 和 ClickOnce）放入部署服务器并更新自动更新所需的清单；
更新开源项目的“下载”页面；
通知所有相关方关于构建和结果。

score 1 · Accepted Answer

How about embedding a build-time timestamp into each built image?

<ItemGroup>
  <StampFile   Include="BuildTimestamp.cs"/>
</ItemGroup>

<Target Name="BuildTimestamp" 
        Outputs="@(StampFile)">
  <Message Text="Building Timestamp..." />
  <Touch
     AlwaysCreate = "true"
        Files="@(StampFile)" />

    <WriteLinesToFile
        File="@(StampFile)"
        Lines='public static class Build { public static string Timestamp = "%(StampFile.CreatedTime)" %3B }'
        Overwrite="true"/>
</Target>

You could extend this to include Machine name, phase of the moon, etc.

score 1 · Accepted Answer

我们使用'checkstyle' ( http://checkstyle.sourceforge.net/anttask.html ) 来生成一个代码报告，这些代码可以新签入并且在开发人员构建之前没有（正式）审查。此外，我还编写了一些执行以下操作的自定义任务：

检查数据库连接属性并尝试与数据库建立实际连接（简单的 JDBC 代码）并报告是否存在任何用户凭据问题等。
将上次构建的用户名和时间戳添加到代码中
向我们的企业 IM 客户端（自定义列表）发送构建状态的通知

还有更多任务，但它们特定于内部环境相关设置。

score 1 · Accepted Answer

我们做了很多：使用 MSBUILD

获取资源
使用时间戳和文件信息和版本信息中的最后一个变更集更新程序集信息
编译：）
使用 Galio 运行测试
创建具有当前时间戳的测试报告并在 IIS 上发布
创建所有必要二进制文件的 Zip 包
在 SVN 上发布 Zip 包
从 TFS 取消绑定 SLN 文件
删除所有 bin/obj 文件
在 SVN 上发布源代码
在构建成功或失败后发送电子邮件
使用 NANT 脚本部署应用程序

score 1 · Accepted Answer

我真的很惊讶没有人提到更新配置文件！我们根据我们为使用构建脚本而构建的环境更新我们的配置文件 b。它可以节省至少 20 分钟来替换所有 connectionStrings 和 appSettings。我们做的其他事情是：

更新版本号
移至测试服务器
运行代码分析
电子邮件构建状态
运行一些数据库脚本

score 1 · Accepted Answer

对于 Java，您还可以使用 Ivy 自动抓取任何丢失的库。例如，如果您使用 Hibernate，您可能希望也可能不希望在您的发行版中包含这些库。

score 1 · Accepted Answer

在构建后步骤中重置测试数据库：

准备一组文件（使用TemplateFile任务）

使用这些文件

删除测试数据库
备份中央数据库
将其还原到新的测试数据库实例
在测试数据库中运行初始化 sql 脚本（使用Sql.Execute任务）
将（使用Xml.XslTransform任务）xml 数据文件转换为 sql 文件（插入）
在测试数据库上运行它们

在此之后，我们有一个干净的测试数据库，具有正确的模式，来自中央数据库的所有固定数据，然后是一些额外的测试数据。

如果架构和固定数据也位于可比较的数据和 sql 文件中会更好，但那是 WIP。中央数据库还没有，但应该在源代码控制中。

score 1 · Accepted Answer

我们做了几件事：

对所有 exe 进行数字签名
归档 pdb
使用 WIX 创建安装程序
为在 CD 或 DVD 上分发的软件生成完整的 .iso 文件

score 1 · Accepted Answer

我们有一个构建脚本，它自动标记构建和 SVN，并将应用程序部署到 WebSphere 应用程序服务器。

score 1 · Accepted Answer

1

运行单元测试和代码分析工具，如 NDepend、Gandarme。结果由CC.Net发布

于 2009-05-29T14:48:39.123 回答

score 1 · Accepted Answer

除了这里已经多次提到的版本控制、签名和测试等，我们还：

为 sharepoint-dll运行spdisposeCheck
运行sigcheck（来自 sysinternals）以创建一个很好的版本概览和应用的证书

score -3 · Accepted Answer

处理其他紧迫的最后期限或赶上电子邮件（等待这并不酷，或有趣......）好吧，这就是我真正要做的：http ://samurai-ryan.mybrute.com/

tfs - 您在构建自动化期间做了哪些很酷且有趣的事情？

31 回答 31

Related

Reference