为Sitecore设置开发环境的最佳方法是什么？

Question

一般指导似乎是将Sitecore安装到一个文件夹中，例如D：\ Websites \ MyWebSite然后在单独的文件夹中创建Visual Studio项目，例如C：\项目\ MyWebProject。然后，您可以将自定义代码从Visual Studio发布到Sitecore文件夹中（此视频在大约13分钟内解释了我所描述的https://www.youtube.com/watch?v=i3Mwcphtz4w）。

我有以下问题： -

1. 人们只将他们的Visual Studio项目存储在源代码管理中，而不是Sitecore代码吗？
2. 从VS到Sitecore文件夹的发布选项仅包含添加文件或删除VS项目中不存在的任何内容的选项。如果不手动删除从VS项目中删除的文件，将如何被删除？
3. 我们使用web-deploy将站点发布到登台和实时环境。在这种情况下，您是否会从VS项目发布，或者您是否设置了发布Sitecore文件夹的方法（如果是这样）？
4. 这实际上是一个很好的设置，或者你做了不同的事情吗？

Answer 1

几年前，当我们开始Sitecore开发时，我做了很多研究。我记得读过Sean Kearney的一篇文章，这对我来说很有意义：http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore

我们最终将这种方法用于大型和小型项目，并且非常棒。您还需要查看其他几个工具：

• 来自Hedgehog Development的Sitecore（TDS）团队开发（http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx）
• 来自Igloo的CopySauce（http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/）
• Visual Studio的SitecoreRocks

所以回答你的问题：

1. Sitecore项目的所有代码和部分都存储在源代码管理中。您要采用的方法是仅存储您创建的新Sitecore项目（布局，子布局，模板等）以及您可能需要自定义的任何项目。您不需要存储所有sitecore源，内容或模块......只需要重新应用以获得最新的环境。您可以手动管理，但像TDS这样的工具可以让您更轻松。
2. 我们使用TDS来管理我们每个环境的发布/部署。 TDS具有可配置的设置，用于处理已删除的项目，包括将其移动到Sitecore回收站或将其删除的功能。你必须小心这一点，但它确实有效。
3. 我们使用单独的构建环境来使用TDS和Jenkins组装和运行部署。基本上，所有代码都从源控制系统检索到Sitecore服务器，并使用MSBuild和TDS构建。在大多数情况下，我们直接使用webdeploy到Sitecore webroot，但是对于生产，我们构建TDS包然后在每个Content Delivery Server上运行它们
4. 到目前为止，我们已经将此设置用于7个sitecore项目，我对它的运行方式非常满意。我们质疑TDS是否值得许可费，但答案总是回归是肯定的。替代方案对我们的开发人员来说并不是很有吸引力，节省的时间远远超过成本。

Answer 2

1. 所有内容都存储在源代码管理中！...并不总是与它们驻留在Web服务器上的区域相同。将Sitecore文件夹存储在源代码管理中是一个好主意，因为您在安装模块时会有更改，但是您不会将Sitecore文件夹添加为您的解决方案/项目的一部分，如果需要，应该真的可以从中获取而不是甚至被跟踪/监控的东西。

2. 安装Sitecore后，创建一个驻留在网站文件夹中的新项目，只添加属性文件夹，布局，xml和其他所需文件夹。我甚至没有在我的项目中包含app_config。哦，要明确的是，最好将Sitecore文件夹保存为源代码管理中的一种引用文件夹，但不能作为网站主干的一部分。我们在源代码管理中的网站文件夹的忽略列表中有它。但是，话虽如此，请记住，您需要将它放在您的网站文件夹中。

3. 从技术上讲，推荐的方法是将Sitecore安装到服务器本身作为一个独立的空实例..就像使用安装程序与客户端模式（不完整）一样，这样你就可以获得一个空的框架网站到位。然后你可以创建部署包/ packages /，它们都是你自己的代码。您应该永远不必手动更改/删除基本Sitecore文件系统。

4. 见上文。一般来说，除非您有理由这样做：将Sitecore安装为空实例...然后通过部署管理您的代码/文件，只留下Sitecore文件夹文件。您将没有理由在升级之外触摸它们或Sitecore文件夹本身。

Answer 3

1. 应避免将Sitecore本身添加到源代码管理，因为您不会在实施过程中部署Sitecore。对于修改到Sitecore本身，您需要一种方法来处理实现中的内容，但配置补丁系统和其他机制为此提供了方法。

2. 网站文件夹中的冗余文件只会是开发环境中真正的问题。发布到演示环境或实时环境时，您只会发布实际需要的材料。基于部署的设置开启了始终从干净的Sitecore安装开始的可能性 - 只要您将Sitecore修改作为实施的一部分（视频中未涉及）。因此，在现实生活中存在这种问题的风险很小，视频中的开发方法可以完全消除这种风险。

3. Sitecore安装应在您的实施部署的外部处理。

4. 这是一个很好的设置，因为视频中的方法是 Sitecore建议用于开发的方法，它也是Sitecore 在开发课程中向开发人员教授的方法。这种方法最明显的优点是

   • 清除网站实施与Sitecore安装之间的分离。不存在意外破坏Sitecore安装的风险，并且不存在忘记运行站点所需的Sitecore非托管手动修改的风险。如果您没有在视频中使用该方法，则很难实现这种分离。

   • 通过使用发布来部署您的实施，您知道您的实施可以在干净的Sitecore安装之上进行部署 - 并且可以正常工作。这意味着在将来部署到生产或演示服务器时，事情将会起作用，并且不会有任何意外。如果您没有在视频中使用该方法，则很难确信。

   • 要在不同版本的Sitecore上测试您的实施，您只需部署到不同版本的全新安装即可。如果您没有在视频中使用该方法，则很难测试。

有sample source code for the video on GitHub，以及如何设置开发环境的说明，包括发布部分。此示例源直接和间接地回答了您的一些问题。