【问题标题】:Teambuild / MSBuild and stamping QA-approved buildsTeambuild / MSBuild 和冲压 QA 批准的构建
【发布时间】:2011-03-11 04:59:18
【问题描述】:

我们使用 tfs/teambuild 和 msbuild 为我们的软件建立了一个自动化的构建和 QA 流程,并且我们希望能够(出于审计目的)知道某个组件是否经过了该流程。

例如,如果一个库安装在用户的机器上,我希望能够以某种方式检查它,以判断它是否通过了构建。特别是,我希望能够将它与直接构建在开发者机器上,然后手动安装的组件区分开来。

最好的方法是什么?作为构建过程的一部分的代码签名似乎最接近这些要求,但大概这不会涵盖可能使用的任何第 3 方库?我还阅读了有关将所有程序集合并为一个的 ILMerge 工具,但是我不知道是否可以对它们进行签名?

我确定我们不是第一批有此要求的人,因此请四处寻找可能做过此类事情的其他人的任何想法或提示

谢谢!

【问题讨论】:

  • 您需要更多地描述您的场景。根据您的描述,不清楚您为什么要这样做。这对于获得一个好的答案很重要。

标签: tfs msbuild audit


【解决方案1】:

我们的开发人员构建设置为将版本保持在“0.0.0.0”,但我们的构建服务器根据预配置版本和自动生成的构建字符串标记构建。 “1.0.3.xxx”。您的构建服务器不允许这样做?

【讨论】:

    【解决方案2】:

    您的构建过程应该更新您的每个项目 assemblyinfo.cs 文件(或全局链接的等效文件),您可以使用 TFS 变更集编号执行此操作,因此就像之前的海报指出的那样,您最终会获得每个 dll 上的属性1.0.changeset.buildno 或类似的东西。您可以在 msbuild 中轻松完成此操作。 您可以在源代码管理中将每个程序集信息文件的值设置为明显的值,例如 0 或 999。

    不过,您的很多问题也与流程和培训有关。 如果您使用安装程序或 zip 来打包您的可交付成果,那么您还可以在构建过程中使用构建号标记它们。 但是,如果你有变更集,你就有了从 dll 到代码的链接,因此可追溯,再加上每个 csproj 中定义的第三方 dll 引用的链接。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-10-24
      • 1970-01-01
      • 1970-01-01
      • 2010-10-17
      • 1970-01-01
      • 2021-11-21
      • 1970-01-01
      • 2018-03-28
      相关资源
      最近更新 更多