2

情况 - 我们有一个带有 WCF 层的 .net mvc 解决方案。该解决方案有大约 20 个被编译成 DLL 的奇怪项目。该站点在 SQL Server 2008 上运行。我们将解决方案文件夹中的 SQL 脚本作为版本进行维护。所以我们有 SQL 脚本，例如。版本 1.0.0.0 可以说是最新的 3.0.0.1。

该解决方案在 TFS 中进行源代码控制，我们也使用 TFS 来管理工作项、错误等。SQL 脚本文件也在 TFS 中

问题 - 问题是我们是否也需要组装好的 dll 上的版本号。我们的 DLLS 不会以任何方式或从外部世界暴露，它们只是在 mvc 应用程序的运行时中。我们不会将 WCF 暴露给外部客户端，它只是由 mvc 应用程序使用。

部署过程只是针对最新数据库的最新代码，因此当我们部署时，我们检查数据库的版本并运行工具将其升级到解决方案中数据库项目中的最新版本。

我们的一位高级架构师说我们也应该在程序集中维护版本号。我是说我们不需要代码中的任何版本号。因为 TFS 管理它。当我们发布时，我们只需使用最新的程序集/部署包部署最新的代码。

我没有遇到过程序集版本，除非它们是向外界发布的程序集（如果你知道我的意思）

请您提出建议... 另请注意，我们不进行功能开发，它只是版本号，以便我们知道特定数据库的版本。

4

2 回答 2

1

我更喜欢知道并能够仔细检查版本的安全性。如果发布过程有问题，或者有一个表现出来的错误似乎是一个发布问题，我希望尽快排除这些问题。我还认为它很容易实现，你花了更多的时间讨论和思考它，而不是你实际花在它上面的时间，而且我想不出它没有任何缺点。

于 2013-01-22T15:43:53.147 回答
1

在我工作的一个类似项目中，我们使用版本号。

针对版本控制系统 (VCS) 的每次提交都会导致我们的 CI 服务器 ( TeamCity ) 构建一个新的工件，并将版本设置为“最新”。“最新”的每个成功构建都会自动部署到我们的测试环境中。理论上，我们也可以将这个“最新”版本部署到生产环境中，但我们没有。

当我们想将一个新版本部署到生产环境时，我们会运行一个不同的手动构建作业，它会创建一个版本化的版本（例如 1.4.7）。构建作业还会创建当前代码库的SVN“标签”。为了让我们的 DLL 具有适当的版本，我们使用了 TeamCity 的AssemblyInfo Patcher功能。这样，我们就不必经常手动更新我们的项目AssemblyInfo.cs文件。相反，他们总是有这样的占位符版本信息......

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

这些数字会在 TeamCity 构建期间自动更新。版本化的工件（包括任何相应的 SQL 脚本）被保存到我们的“Releases”目录中，我们保存所有版本的代码库。

现在这一切似乎有点过头了，对吧？并不真地。

这给我们带来了以下好处......

  • 我们的部署过程wget对我们的监控页面进行了处理，该页面列出了版本号并断言版本匹配（预期已部署的版本与服务器上当前运行的版本）。这让我们相信我们的部署过程正常工作。
  • 如果在版本化版本（生产候选版本）中发现错误，我们可以 SVNcheckout标记、应用修复并创建新版本，而不必担心主干上可能危及版本的其他更改。很难一直保持“可发布”，这允许不必这样做。虽然，不要误会我的意思，它有它的优点。
  • 如果在版本化版本中发现问题但无法快速解决，您始终可以重新部署已知可以工作的旧工件。能够将已部署的版本恢复为旧版本无疑为我们节省了几次。
  • 如果在生产中发现需要调查的错误，我们可以自由地将相同的版本化工件部署到我们的任何测试环境，以便我们可以尝试在生产环境之外重现问题。

我目前可能忘记了更多优势，但上面的列表应该大致了解适当的版本管理可以带来的力量。

我建议不要持续手动更新 20 多个项目的版本文件。这似乎是很多忙碌的工作，主要是浪费时间，因为它容易出现人为错误。无论您决定做什么，都将其自动化并验证结果。

于 2013-01-22T16:05:42.693 回答