22

我目前正在开发一个项目（只有我自己），并且我已经知道如何处理它的版本控制。我用的是经典的<major>.<minor>.<build or patch>。

我遇到的问题是我想在我的一些提交中包含指向相应版本的标签，但我不想手动执行。

现在我正在做：

  • 如果我要发布v0.2.13，我会更改AssemblyInfo.cs并设置该版本
  • 在 Git 上提交更改
  • 在 Git 上添加标签v0.2.13（手动）
  • 构建项目
  • 创建一个.zip文件（不是所有时间）并将其命名为ProjectName v0.2.13

我做错了吗？

我可以轻松地创建一个脚本来自动执行最后一步，但我想知道是否有关于自动化另一部分的好习惯？

4

5 回答 5

8

我在 MSBuild 中有一个构建脚本，它会自动检索当前签出的 git 提交，然后在构建时将这样的属性添加到程序集：

[assembly: AssemblyInformationalVersion("0.2.13+e3a6f2c1")]
[assembly: AssemblyVersion("0.2")]
[assembly: AssemblyFileVersion("0.2.13")]

版本的数字部分来自我的构建脚本读取的 version.txt 文件。

程序集版本缺少第 3 个八位字节，因为它在您增加内部版本号时避免了绑定重定向要求。AssemblyFileVersion 包含该属性允许的所有数据，AssemblyInformationVersion 可以是您想要的任何字符串，因此使用语义版本控制来包含 git commit id 允许您准确指示构建此项目的源版本。

然后在构建成功后，您可以根据需要添加 v0.2.13 标签。就个人而言，一旦我构建了最终版本，我就会增加 version.txt 文件，以便所有后续构建都具有下一个更高的版本号。之后的每个构建都将具有该版本，直到我发布该版本，标记提交，再次增加 version.txt 文件并重复。

顺便说一句，该AssemblyInformationalVersion字符串出现在 Windows 资源管理器的文件属性中，因此这提供了一种从任意构建的二进制文件到匹配的原始源代码的有保证的方法。此外，不幸的是，这种方法会导致 csc.exe 报告 AL???? 构建警告，因为语义版本格式不符合 xyz 语法。但这并不意味着任何东西都被破坏了，我只是忽略了警告。

我从不明确压缩源代码，因为这与源代码控制的责任是多余的。至少如果您的源代码是由某些在线服务托管的（甚至是在您的私有 Intranet 上），大多数 git 主机已经为给定的提交 ID 提供了即时下载为 zip 的功能。

于 2012-12-28T16:03:29.000 回答
1

提交后，我对所有内容都使用Makefiles。

根据您的构建系统的工作方式，您可能能够添加一个目标“发布”，它标记当前分支并推送此标记。您还将添加一个依赖于“构建”和“发布”目标的“包”目标。

如果这不起作用，只需创建自己的 Makefile。您可能需要也可能不需要以不同的方式命名您的“Makefile”。

于 2012-12-23T12:06:22.530 回答
1

如果您没有使用构建服务器的能力，那可能是最好的手动方式。但是，如果您有时间，我强烈建议您安装某种类型的构建服务器。我们在TeamCity方面取得了很大的成功。如果您将其设置为跟踪您的存储库，则有多种方法可以进行程序集信息修补、标记和构建后部署（有很多可能的链接，我建议您只需点击文档即可）。

在设置我们的版本控制时，我发现这篇文章很有帮助；你几乎可以排除 NuGet 位，它应该有一些不错的信息。就设置 TeamCity 而言，只需快速搜索“TeamCity 设置教程”，您就会拥有大量资源。祝你好运！

于 2012-12-28T15:55:55.820 回答
0

我已成功使用以下步骤来完成类似的事情：

  • 将新提交推送到共享的 git 存储库
  • TeamCity 服务器签出代码、运行测试并构建项目
  • 如果成功，TeamCity 还会移动/删除/打包部署包的文件
  • 然后它将 zip FTP 到部署暂存区域，可以手动部署它（这可以完全自动化，但我们的设置很奇怪）

您可以使用提交后挂钩来标记您的分支并推送到您的 TeamCity 服务器。

于 2012-10-16T22:43:38.637 回答
0

南特满足您的需求！检查这个：NAnt任务参考

它易于使用并与 git 存储库结合 :-)

于 2012-12-28T15:49:32.273 回答