2011-09-20 27 views
2

我们有一个.NET Web应用程序,其中包含TFS 2008上的172个项目,其中包含应用程序的所有3层应用程序并使用Team Build for CI。我们使用VS2010进行开发。使用TFS 2008启用代码分析,并产生极端影响

我们希望通过最小推荐规则集激活所有项目的代码分析,并强制执行TFS签入策略,即在签入之前应该运行一次代码分析。但是,我们希望对我们的影响最小开发人员正在进行常规开发检查。每次我们在一个项目的属性中启用代码分析时,该项目的正常构建时间就会增加100%。 我们对代码分析问题进行了分析,尽管这些规则集中有很多这样的问题,但它可以分发给所有可以在完成现有增强功能时修复它们的开发人员。

所以基本上我们有两种类型的构建,我们做:

  1. 师范大学建立检查之前,我们签入的代码发生几次代码的正当性。
  2. 就在我们还想检查代码分析的签入之前进行最终构建。

因此,我们创建了一个名为“DebugWithCA”的另一个解决方案配置,其已经为代码分析启用的项目,使之前开发商签入的代码,他换了从调试到DebugWithCA配置,构建和修复了代码分析然后检入。因此,对于正常的构建,开发人员停留在Debug解决方案配置中,并且不必承担由代码分析引起的额外构建时间。

但是这也看起来像一个开销,因为我们在白天有很多签入(许多开发人员),并且每次签入和切换回切换解决方案配置都会变得很痛苦。

有没有更简单的方法来完成我们的要求? 在构建过程中,是否有一个快捷键,我们可以分配它,以便通过代码分析构建或使用VS2010中的特定解决方案配置构建?

回答

0

我可以想到两个实用的方法来规避你的问题。这两个建议都将代码分析放在开发人员的关键开发路径/时间之外。

  1. 在门控登机手续中激活了您的DebugWithCA配置。开发人员只需签入代码,构建系统确保执行代码分析,并且只有当没有违反基本规则时才会接受更改。
  2. 更轻松;只需基于DebugWithCA配置执行Rolling Builds。开发人员可以在线离线提取规则违规。不太可取的选择,但也较少侵入。
+0

谢谢你的回答kroon。我为此得到了一个风滚草徽章:)哈哈。我会尝试你的选择1,并让你知道它是如何结果。 – Kash

相关问题