我理解在多站点Sitecore实例中有关于站点隔离的类似问题，特别是在提及Tim's multi-site solution的情况下，但在尝试完全实现Tim＆＃39;之前，我正在寻求进一步的清晰度。代码。
我们目前正在使用Sitecore实例，该实例目前拥有近十个网站。我们有一个单一的Visual Studio解决方案，它以某种方式将所有站点都提供给一个代码库，这样所有的DLL都是公共的，任何其他文件也可以。我们或多或少已经开始通过将所有站点分解为他们自己的项目来处理这个问题，他们的每个项目结构都反映了单一的最终结构。这仅仅允许更少的流失＆＃34;修改.csproj文件等项目时，减少与并行工作的其他开发人员的冲突。虽然这绝对是一个不错的项目，但它比我们真正追求的更方便。
对于更多背景知识，我们在一个＆＃34; stream＆＃34;中有五个Sitecore实例，它们是本地开发人员的实例，开发实例，登台实例，然后是两个生产实例。我们正在使用Git管理变更。
此时我们无法进行编译更改，例如对任何代码隐藏进行更改，因为它适用于一个站点中的一个项目（这不会影响其他站点的功能），并部署已编译的没有其他网站不得不依赖该DLL而进行更改。这成为一个问题的主要方式是我们无法保证在推出任何代码时所有网站仍会运行;对单个站点的任何更改都可能会立即中断所有站点。曾经有过这样的情况：我将代码更改错误地部署到破坏所有站点的开发中，因此这是一个完全实现的问题。我们也不希望每次有代码更改时都要测试每个网站，当我们在不久的将来在Sitecore中拥有超过30个网站时。
或许Tim的多站点解决方案可以做到这一点，但有没有办法真正隔离网站，以便他们不依赖于相同的DLL？那么我们可以为每个网站提供单独的Visual Studio解决方案（我认为这是理想的）吗？我已经看到其他答案提到了蒂姆的解决方案＆＃34;隔离＆＃34;，但这对我来说太模糊了。蒂姆的解决方案在多大程度上隔离了＆＃34;隔离＆＃34;网站？有更好的解决方案吗？
答案 0 :(得分：0)
单个Sitecore应用程序实例本质上是一个或多个前端站点的虚拟主机环境。每个站点都由布局和UI组件组成，这些组件可以共享但不必共享。也就是说，您可以跨每个站点的单独项目或解决方案复制组件，这将解决该问题。但是，它会在所有站点上打开另一个重复代码的问题。修复一个问题，你需要多次。此外，当您部署DLL时，它将回收应用程序池，以便所有站点都将重新启动，因为它是相同的应用程序实例。我能给出的最好的指导是组织起来并有一些编码治理。也许应该非常小心地改变所有可能容易破坏多个站点的站点使用的一组常用实用程序。特定于站点的组件更多地位于边缘并且影响较小。此外，不要将UI组件与常用实用程序中的太多继承层和代码耦合。虽然它在逻辑上可能有意义，但它会产生很多可能导致问题的耦合。根据相同挑战的经验，我只需2美分。
在我们的案例中，我们有一个由所有站点共享的核心实用程序库，一个用于共享UI组件的核心Web项目，然后为这些站点中的组件分离特定于站点的Web项目。我们还尽可能避免全局配置更改以及事件和管道等功能的“过度修补”。而是尝试将代码保持在特定站点的范围内。
答案 1 :(得分：0)
如果您需要真正隔离 Sitecore网站和部署，您可以选择一个模型，其中每个网站都有自己的解决方案，IIS网站（和应用程序池），部署管道和所有共享功能/配置通过NuGet包完成。在此模型中，您有一个CM服务器，其中所有站点共享Web。
此外，您可以在每个站点上使用自定义事件提供程序隔离发布，该站点仅提升与给定站点的项目相关的事件，以便在每次发布时不会在所有站点上清除缓存。
这种隔离方式目前正在生产中，每个服务器有70多个站点，约有80个开发人员分布在~10个团队中。