Sitecore 8.2升级：源码控制与工作流优化中的静态配置管理疑问

Hey Gregory, great question—this is such a common pain point when locking down Sitecore source control and deployment workflows, especially during an upgrade. Let’s break this down clearly:

是否应将所有无需变更的.config文件纳入项目与源码控制？ #

绝对应该。你担心的文件搜索负担完全是小问题，现在的IDE（比如Visual Studio、Rider）都有强大的过滤和搜索工具，完全可以忽略这点。而不纳入这些文件的弊端要严重得多：

• 手动管理目标环境的配置文件夹很容易出错（比如遗漏文件、版本不匹配、忘记更新）。
• 用自定义脚本同步配置会增加不必要的维护成本，还会破坏你“单一可信源”和“可重建整个站点”的核心目标。

把所有需要部署的配置文件纳入管理，完美契合你的两个核心目标：你会拥有一个可信任的单一来源，包含重建站点所需的所有文件，并且无需手动干预就能完全复制环境。

你可能忽略的关键要点 #

1. 区分Sitecore核心配置与自定义补丁
   不要直接修改Sitecore自带的核心配置文件，比如Sitecore.config或Web.config。而是使用Sitecore的补丁机制（App_Config/Include目录下的文件）来覆盖设置。这样你只需要在源码控制中跟踪自定义补丁文件即可——可以在仓库的专用文件夹（比如sitecore-official-configs/8.2）中保存一份官方8.2版本的核心配置作为参考，然后通过Sitecore安装框架（SIF）等工具部署这些核心配置，无需将它们纳入主项目。这能让你的仓库更整洁，也简化了未来的升级工作。

2. 避免“隐性”的环境专属变更
   即使某个配置不需要常规变更，也要确保所有环境专属的调整（比如调试标志、Gulp转换中没覆盖到的连接字符串）都通过自动化流水线处理，而不是手动修改目标服务器上的文件。如果确实有罕见的一次性变更，要在仓库中记录并添加到部署脚本中，确保变更可重复执行。

3. 用.gitignore清理仓库
   确保你的.gitignore文件排除Sitecore自动生成的文件，比如*.config.bak、日志文件和临时文件夹。这样可以让仓库专注于你真正需要管理的文件，避免被临时数据 clutter。

其他Sitecore从业者的常见做法 #

• 采用Helix架构：大多数遵循Helix（Sitecore事实标准架构）的团队，会在模块项目中跟踪所有自定义配置补丁。Sitecore核心配置通过自动化工具部署，但官方版本会存储在仓库中以便追溯。
• 结合部署流水线实现配置即代码：团队使用Octopus Deploy、Azure DevOps Pipelines或TFS等工具，从源码控制拉取所有配置文件，应用Gulp转换，然后一步部署到目标环境。这确保每个环境都能获得完全相同的文件，没有例外。
• 不可变环境：有些团队更进一步，将环境视为不可变的——不在服务器上编辑配置，而是每次有变更时从源码控制重建整个环境。这完全消除了配置漂移，让你“重建整个站点”的目标变得轻而易举。

归根结底，仓库里多一些文件带来的小麻烦，和拥有完全可重复、一致的部署工作流带来的安心相比，根本不值一提。你的Gulp转换已经走在正确的路上——只要把那些静态配置文件加入项目和仓库，就能轻松达成你的两个目标。

内容的提问来源于stack exchange，提问作者Gregory Mertens