Gregory Mertens
Gregory Mertens

Reputation: 554

Sitecore Config Files + Project Setup

We are updating our sitecore to 8.2 and in the process I am trying to refine our source control and development workflow.

Goals 1. Have a single source of truth for support dlls, configs, lic, etc. 2. Have everything in source control that is needed to recreate the entire site from dev to prod. (excluding packages).

In order to have all of the different configs needed for the various machines I have created gulp tasks that transform the configs on build (dev, staging, prod). Those transformed configs are placed in a folder in the project that is then used to replace the originals on the target machines. This folder publishes all of its contents and seems to be working well so far.

What I don't know is how to deal with all of the config files that do not change.

Is it best to include all of those .config files in the project so that they publish? If not, then the target machine folders will have to be either manually managed (seems like a bad idea) or a script used to ensure the configs are up to date (more customization..by default not a great idea).

The only downside (that I see) to including all of the configs in the project is the weight that it would add to file searches (and that doesn't seem like a very strong argument).

Am I not seeing something?

How are you other Sitecore humans handling this?

Gregory

Upvotes: 0

Views: 104

Answers (1)

jammykam
jammykam

Reputation: 17000

As a general rule of thumb, do not check in any default files into Source Control.

The main reasons are; bloat, making syncing/downloading from your source control take much longer, and upgrades, the latter being a much more important reason.

If/when you upgrade in the future, if you do not have any Sitecore files checked into source control then you can simply deploy a new/clean instance of Sitecore, fix any conflicts in your own code and then deploy on top. You don't have to try and figure out what has changed in the default install files between releases.

Any changes you need to make to Sitecore configs or settings should be made using patch files and only those custom files added to your solution.

How to handle this for deployments?

There are a few options. You could go done the scripted route, which will take a clean Sitecore install, unzip and made whatever modifications you need, then install/unzip the modules that you use in your solution one by one.

Another option maybe to create a default install with all the modules and then zip this up, then an install would be similar process to above but a more simpler case of just unzipping a single file. You could use Sitecore SIM to both install the instance, modules and then backup or do this manually.

Yet another alternative may be to check everything into Source Control, either under separate repository or a different project so ensure that all default files and configs are kept separate. If you need to upgrade in the future, simply delete the repo/project and add them back in again.

I would also do the same (a separate project) to keep all Support patches/dlls separate, again to help easily identify what fixes have been applied and to easily remove them if a future version resolves the issue.

These may add an additional step to your deploy, but keeping this separation will make your life much much easier when it comes to upgrade time.

Upvotes: 1

Related Questions