多个网站引用的类库+版本控制分支答案

【问题标题】：Class library referenced by multiple websites + version control branching多个网站引用的类库+版本控制分支
【发布时间】：2014-11-11 21:06:31
【问题描述】：

考虑以下 -

我有一个包含多个项目的解决方案：

Website1 和 Website2 共享一个对 BusinessLogic 的引用，而后者又引用 DAL。

由于这些只是网站，因此我不需要跟踪多个版本，但我确实希望拥有以下分支：

Trunk 是我完成所有开发工作的地方，在一切都经过测试并准备就绪后，当网站实际部署到生产服务器时，我会从 Trunk 合并到生产。这使我可以搁置当前的工作，检查生产分支并解决部署后发现的任何重大错误并立即部署修复程序。

我的问题是，使用这种方法，生产分支中的内容并不总是正确的。假设我对 Website1 使用的 BusinessLogic 进行了更新。它通过了测试并被部署。如果我将所有项目合并到 Production 分支，那是错误的，因为当时 Website2 没有部署到生产中。

或者，我可以只将相关项目合并到生产中。因此，在这种情况下，我将合并 Website1、BusinessLogic 和 DAL。然而，这仍然是错误的。如果我要检查生产分支以在 Website2 上工作，它将具有比我们生产服务器上实际存在的新版本的 BusinessLogic 和 DAL。

这里的正确方法是什么？

【问题讨论】：

【解决方案1】：

您不应使用代码共享或代码提升模型。它降低了质量并迫使返工。而是寻求创建一个发布管道，您可以在其中为您的业务和 Dal 层创建一个包，并使用那些打包在 Web 应用程序中的内容。

最好的方法是使用构建服务器并为业务层使用的 DAL 创建 NuGet 包。这又被打包为您的网站可以使用的 NuGet 包。

然后，您将业务层更改到您的网站的工作流程是：

干净简单。没有分支就是好的分支。

【讨论】：

【解决方案2】：

可能有很多正确的方法，它总是取决于什么对你来说是正确的。当然，每种方式各有利弊。

如果您想要源级依赖项，请为每个站点创建多个生产分支，每个分支都包含外部：

以下是执行版本升级的方法：

所以你会有 -

这需要一定程度的开发文化和一定程度的svn管理。

您还可以将二进制文件放入此类 svn 分支，这与方案几乎相同。一般来说，这种方法被命名为vendor branches。

如果您更喜欢源代码控制之外的二进制依赖项，您可以使用本地 nuget 存储库。它的工作原理与官方版本相同：您创建一个新版本，发布到 nuget，然后从站点、构建和部署中引用它。这需要额外的设置和维护工作，更适合大型项目。

【讨论】：

使用分支来解决这个问题是不正常的，会导致代码质量长期下降和重大返工。
@MrHinsh “这需要一定程度的开发文化和一定数量的 svn 管理。”如果你仔细阅读的话。当然会的。但总的来说，代码质量取决于编码器。有些甚至可以破坏黄金密码的降落伞。我没有看到使用只读供应商分支的任何问题。此外，从技术上讲，它只是另一种形式的相同代码。您可能还注意到，我也建议通过 nuget 进行二进制分发。它带来与非二进制相同数量的问题，问题本身不同。如果您愿意，这只是旧的源与二进制圣战。
代码共享从来都不是解决这个问题的正确方法。您最终会得到多个包含相同编译代码的不同 dll。这是错误的，不应该被鼓励。