Fatal编程技术网
  • version-control/
  • Version control 使用TeamCity进行程序集版本控制

Version control 使用TeamCity进行程序集版本控制

version-control teamcity

Version control 使用TeamCity进行程序集版本控制,version-control,build-automation,teamcity,Version Control,Build Automation,Teamcity,我正在从事一个使用SVN和TeamCity build server的C#/VB.Net项目。构建生成了十几个程序集。我想控制程序集版本，以便它们都匹配，并且也匹配TeamCity构建标签 我已将TeamCity配置为使用的构建标签 大调.小调{Build}.{Revision} 其中，主版本和次版本是我手动设置的常量，{Revision}由签出时的SVN存储库版本确定，{Build}是TeamCity自动递增的生成计数器。因此，构建标签的示例如下 2.5.437.4423 您建议使用什么技术来

我正在从事一个使用SVN和TeamCity build server的C#/VB.Net项目。构建生成了十几个程序集。我想控制程序集版本，以便它们都匹配，并且也匹配TeamCity构建标签

我已将TeamCity配置为使用的构建标签

大调.小调{Build}.{Revision}

其中，主版本和次版本是我手动设置的常量，{Revision}由签出时的SVN存储库版本确定，{Build}是TeamCity自动递增的生成计数器。因此，构建标签的示例如下

2.5.437.4423

您建议使用什么技术来确保所有程序集版本都与TeamCity build标签匹配？

我们使用的是CruiseControl.net和SVN。我们把车开到另一个方向。我们正在使用MSBuild脚本中的版本任务来增加CI生成的版本号，并使用该版本号来标记源代码

编辑：询问有关MSBuild目标的更多详细信息…
我们使用一个单独的脚本，用于CI构建，而不用于开发人员构建。我们尝试在studio用作项目文件的MSBuild文件中使用不同的目标，但这会让人头疼，需要手动编辑studio生成的文件。
MSBuild文件的结构非常简单：

  • 进口额外物品



  • BeforeBuild：设置新版本号并重写AssemblyInfo文件







  • 生成：在发布模式下生成实际的项目文件MSBuild脚本

  • AfterBuild：我们运行单元测试项目（防止在接下来的步骤中为损坏的构建创建标记），使用SvnInfo任务和一些RegexReplace任务设置一些带有路径和标记名的变量，并使用SvnCopy任务创建标记

    • 我建议使用TeamCity的AssemblyInfo补丁程序构建功能：

    只需从VisualStudio创建项目，在BuildSteps页面中配置构建功能（请参见），只要保留默认的AssemblyInfo.cs文件，它就可以工作

    这种方法对我来说非常有效

    优点：

    • 开发人员可以在他们的机器中构建解决方案
    • 您不需要触摸.sln或.csproj文件。它只是工作
    • 通过使用TeamCity变量，您可以轻松地使版本号与其他项目的版本匹配，等等
    缺点：

    • 您无法轻松地从TeamCity切换到另一台CI服务器，因为您没有构建脚本（但切换CI服务器就像切换ORM或数据库：这不太可能，而且无论如何都需要大量工作）
        • 我将哈米什的答案作为公认的答案，但为了完整起见，我认为值得记录我们最终采用的方法

        我在TeamCity中维护两个独立的构建配置，一个是CI构建，另一个是每周在有任何更改（或手动）时运行的构建，这是我们的正式发布构建。我选择了双构建方法，因为构建可能需要40分钟的端到端时间，我希望开发人员在提交更改时能够快速获得关于任何构建问题的反馈。因此，CI构建是完整版本构建的子集，但它确实构建了所有代码。两个版本之间的版本控制也不同：

        • CI生成的版本号为{Major.minor.BuildCounter.SvnRevision}
          • BuildCounter从0开始
          • 不标记svn存储库
        • 每周/发布版本有一个类似的版本控制系统，但是
          • 生成计数器从（主*1000）开始，因此如果主是“8”，则生成计数器从8000开始
          • 在svn存储库中创建名为“Build{Version}”的标记
        这种随意选择的原因是为了让我们能够清楚而简单地区分CI构建和发布构建

        我们有一个名为AssemblyVersionInfo的解决方案范围的文件，它包含在解决方案中的每个项目中（软链接）。该文件（本质上）包含以下内容：

        因此，开发人员构建都使用相同的静态且易于识别的版本号，该版本号高于构建服务器生成的任何版本号，因此在版本控制冲突中，开发人员的文件获胜

        在生成服务器上，我们使用MSBuild社区任务生成一个新的AssemblyVersionInfo文件，该文件覆盖默认内容。我们使用TeamCity构建字符串作为新版本。这样，我们可以很容易地区分以下三种情况：

        • 在开发人员工作站上执行的私有构建
        • 在生成服务器上执行但不应发布的CI生成
        • 正式批准的发布版本，在Svn存储库中标记
        另一方面，请注意我设置的是
        AssemblyFileVersion
        ，而不是
        AssemblyVersion
        。我们强制程序集版本为“Major.Minor.0.0”的静态固定版本字符串。我们这样做是为了能够发布bug修复版本，而不必担心版本控制问题。AssemblyFileVersion可以让我们了解用户安装了什么版本，而不必将其作为程序集标识的一部分。

        尽管这已经有了一个公认的答案，但我想补充一个我们使用过的想法

        对于大型项目，可能有许多程序集信息文件需要更新，并且随着不断的重新分解，构建脚本始终存在不知道需要更新的新文件的风险

        出于这个原因，我们创建了一个简单的代码文件，它为实际版本定义了一个常量，然后所有项目都继承了这个常量 
        using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)