What's the Best Practice for Storing Sitecore in the Solution?

Question

So at the company I work, we've always stored the Sitecore instance that we are developing (for the site we are building) in source control. In this instance, we use TFS for source control. (Though I doubt it matters much if it's Git or TFS)

However I've been building a few components for the market place and I've found that not committing the Sitecore instance into source control, is actually a lot easier and theoretically allows me to build my component to work with multiple versions of Sitecore (by firing up different versions using SIM). But does this only make sense when developing components?

That being said, how would I ensure each developer is using the correct version of Sitecore when testing their code that matches the Sitecore version of the client (if I'm not forcing them to use a specific version using source control)?

Also, how would this work with automated deployments? Would I just use the SIM to fire up the specific version of Sitecore from scratch each time and then install/publish the site on top of that fresh instance?

How do you handle Sitecore support fixes in that scenario? Would we need to store those in the Web project? If that's the case, wouldn't those cause issues if we started working with a newer version of Sitecore?

Answer 1

• You should start with a blank web application solution with no /sitecore files at all. If you need to add a file or modify a sitcore file, build the folder structure in your project so on deployment, it will overwrite the existing sitecore file.
• All Sitecore config changes should be in the solution, in a /App_Confif/Include/z_[Client] folder.
• All your dlls for Sitecore should come from the official sitecore NuGet feed where you specify the sitecore version, not using "latest" in NuGet.
• Your web.config should be an out of the box Sitecore web.config and use transforms to make the web.config into what it needs to be on the build.
• You should develop with in the Helix guidelines for your project structure.
• All Sitecore item changes should be tracking in your choice of serialization software. Whether its TDS or Unicorn.

My litmus test is if I can create a site with a Sim tool and deploy my project code and items, does my site work? In some situations, we pull production/stage content from Sitecore using PowerShell, copy the package to a Nuget server and deploy it to development/CI with PowerShell.

To create a site, I have used Sim tools with the command line or this Powershell script.

You are not alone in your frustration. I have run into several clients who have the entier Sitecore web site in their solution. Deployments and upgrades are always very difficult. But if you design a solution that includes no actual Sitecore files and can be deployed to a blank site via CI. Then you will be in great shape.

Answer 2

I think that the best practice is not to store Sitecore in your source control.

So your source control should contain only files that are relative to your solution and on build process you deliver your codebase and files to Sitecore instance directory which is not part of your source control.

So from my point of view:

• do not store sitecore files
• do not store/modify original Sitecore configs, use include patches in your custom config files
• you may keep web.config if you have something custom in it
• Reference only required minimum of Sitecore dlls into your projects. For Sitecore 8.2, use the Sitecore nuget feed
• you may include default Sitecore items if you changed them (actually, avoid that situations)

That approach also simplifies the future Sitecore upgrades so you don't need to sync new version of Sitecore files to your repository.

Answer 3

This question is quite broad as there are many aspects to it. Here is my perspective of this subject. should you add Sitecore files to source control? Only those that are needed for the build to run and that may be changed as part of the development of your website. For example you may want to add Sitecore dlls because they are referenced so if you are working with multiple developers they need to build as well so those are needed for your website to run properly. What about files that are just part of the sitecore package and not planned to be customized? Those I would leave off. There are a few reasons why. If you decide to upgrade Sitecore and all the Sitecore files are in source control the upgrade will be painfull. Also why add to source control something that is not going to change at all?

The same goes for Sitecore items. If you are using a tool like TDS for example, you don't need to add to TDS all items for your content tree. If you do that the sync process will be slow. what do you do? you add only the ones that are part of the development itself and folks should have on their dbs to run the application properly.

you also asked "how would I ensure each developer is using the correct version of Sitecore when testing their code that matches the Sitecore version of the client?" There are a few ways you can do that such as stablishing a process to the developers like working on separate branches for each versions. Using publishing mechanisms to publish your components codes to each sitecore instance so you can test, etc.

that's my 2 cents