如何用CI收紧质量棘轮

Question

我的团队正在使持续集成与我们的所有项目合作。现在我们已经让CruiseControl构建了所有项目，这很不错，但并不是真的很重要。我从NUnit，StyleCop和Code Analysis / Resharper那里得到了更多的回报。

但这是我正在考虑的事情......所以我打开了一个项目的StyleCop，它有七个巨大的违规行为。并且它将会有7个巨大的违规行为，直到它们全部被修复。与此同时，我是否只有一个破碎的构建？这不会掩盖更为重要的构建破坏者吗？

在我看来，理想的是项目基础上的紧缩棘轮......客户A是全新的，因此我们所拥有的每条规则都已启用并打破了构建。客户B是遗产，因此他们的违规行为只会触发警告，我们希望在某些时候我们可以像客户A一样收紧他们的棘轮。

这个概念在CI中是否存在？我怎样才能最好地实现它？

Answer 1

我们关注的重点之一是“没有新的违规行为”。因此，当有新的违规行为时，我们会build tool (AnthillPro)提醒我们。我不确定CC.Net是否可以开箱即用，但你可以玩一些XML比较游戏来获取这些信息。

该方法在初始问题很少或没有初始问题的新项目和现有项目中都能很好地工作。对于现有的东西，花一点时间来完成八千个投诉，看看你是否真的关心，然后从那里继续。

接下来对于大多数群体来说，他们开始部署应用程序并运行功能测试。

Answer 2

我没有使用StyleCop，但是使用FxCop（Microsoft的另一个分析工具），我们创建了两个不同的规则集 - 一个用于使构建失败，另一个不用。构建失败的那个规则是一组相对较小的规则（未使用的代码，未处理的字段等）。构建中没有失败的规则包括拼写和套管之类的东西 - 现在不够重要的项目（或者有这么多违规行为需要永远修复它们。）

当构建运行时，它会调用两次FxCop，每个规则集一次。由于我们使用msbuild来运行我们的工具，因此我们将警告集的“FailOnError”标志设置为false。这让我们可以看到结果，但无论我们可能有多少违规行为，ccnet都不会使构建失败。

Answer 3

您可能需要调查Jenkins。开箱即用它可以让您按照警告的数量触发构建颜色 - 例如，您可以拥有一个绿色构建，在一个项目上有数千个警告，但在另一个项目上有一个红色构建单个警告。

尽管看起来它可能具有Java焦点，但Jenkins非常适合.NET项目，并且有许多插件可以分析，例如Stylecop XML报告。