考虑以下内容 -
我有一个由多个项目组成的解决方案：
Website1和Website2共享对BusinessLogic的引用，而BusinessLogic又引用了DAL。
由于这些只是网站，我不需要跟踪多个版本，但我确实希望拥有以下分支：
Trunk是我开展所有开发工作的地方，经过一切测试并准备好后，当网站实际部署到生产服务器时，我从Trunk合并到Production。这允许我搁置我当前的工作，检查生产分支并解决部署后发现的任何主要错误并立即部署修复。
我的问题是，使用这种方法，生产分支中的内容并不总是正确的。我们假设我对Website1使用的BusinessLogic进行了更新。它通过测试并部署。如果我将所有项目合并到生产部门，那就错了，因为当时没有将Website2部署到生产中。
或者，我只能将相关项目合并到Production。所以，在这种情况下，我会合并Website1，BusinessLogic和DAL。然而，这仍然是错误的。如果我要查看Production分支以在Website2上工作，那么它将具有比我们的生产服务器上实际存在的更新版本的BusinessLogic和DAL。
这里的正确方法是什么？
答案 0 :(得分：1)
您不应使用代码共享或代码促销模型。它降低了质量并迫使返工。而是寻找创建一个发布管道，在其中为Business和Dal层创建一个包，并使用那些打包在Web应用程序中的包。
最好的方法是使用构建服务器并为业务层使用的DAL创建NuGet包。这反过来被打包为您的网站可以使用的NuGet包。
您的业务层更改到您的网站的工作流程是：
干净简单。没有分支是良好的分支。
答案 1 :(得分：0)
可以有很多正确的方法，它总是取决于你的正确方法。当然，每种方式都有利有弊。
如果您喜欢源级依赖项，请为每个站点创建多个生产分支，每个分支都包含外部：
以下是执行版本升级的方法：
BusinessLogic/DevBranch进行更改，然后对其进行测试。BusinessLogic/v2Branch Site2/Production的外部指向BusinessLogic/v2Branch 所以你有 -
这需要一定程度的发展文化和一定数量的svn管理。
此外，您还可以将二进制文件放到这样的svn分支中，这几乎是相同的方案。通常，此类方法名为vendor branches。
如果您更喜欢源代码控制之外的二进制依赖项，则可以使用本地nuget存储库。它与官方版本的工作原理相同：您创建一个新版本，发布到nuget，然后从站点，构建和部署中引用它。这需要额外的设置和维护工作，更适合大型项目。