If you’re looking for the simplest possible developer setup for Sitecore then creating an ASP.Net web project, dropping Sitecore over the top, configuring it for shared databases and checking it in to source control is the answer. Back in the day it was an accepted pattern to to work this way – so you could click “play” in Visual Studio to run your site. And I still find myself workig on projects running that way. But today this is considered a bad idea. So why do I keep finding projects set up this way, and why isn’t it a good approach?
Talking to developers, there are two key positives people bring up with this way of working: Firstly, the developer setup process is very simple. Clone, build and run is much easier than doing SIF installs. And there’s probably an argument that it was also simpler than the older SIM or “just run the .exe” install approaches of the past. This is especially true if you’re working with developers who are new to Sitecore, and still learning what goes where and why. Plus, relatedly, it can make for a very simple onward deployment process. If your entire website is in source control, a deployment can be as simple as clone, build, and drop the files into an IIS website folder. And that works on a blank server – making deploying new instances simple.
But behind those advantages, there are some important challenges. And these are why best practice has moved away from this approach:
- Upgrades are challenging. Once you’ve put all of Sitecore into source control it can be tricky to work out what files are there because they were changed, and what files are just there to support the debug/deploy process. Each time you want to change your Sitecore version you end up having to unpick that. You have a pile of Sitecore files to go through, where you have to check if they’ve been modified by you or by Sitecore. And if you get it wrong you end up with tricky to diagnose bugs.
- Repos are much bigger than necessary. Putting all the Sitecore files into source control adds a lot of bulk. And a big chunk of that is all the DLLs – and source control is not great for storing binaries. When working through upgrades it’s not uncommon for files that are no longer required to get left around. And building from a “Sitecore’s in source control” repository does increase the chances of unnecessary files ending up deployed onto servers, unless you take care to avoid this.
- It fits with the old style “everything is in one project” approach to website development. But it doesn’t work nearly as well when you move over to a Helix style of development. Helix usually works with multiple projects – separating out the different parts and layers of your work. They need to be deployed together in order to run. But if your running from a source-controlled folder then you have a problem to address: You either need to pay really close attention to your git ignore settings, or you can end up with bits of your project getting duplicated into your source control after you “deploy” on top of your “it’s got Sitecore in” project.
- A less common issue – but one that can still bite you is that when you run Sitecore from your web project directory, you’re not using the right disk and process permissions. So code that runs happily in your development instance might fall over on a “real” deployment if it makes assumptions about permissions.
- And a fairly key thing is that this approach does not work if you’re planning to do development that involves work on xConnect. The “stick Sitecore in Source Control” approach means that xConnect isn’t easily available locally. You have to do something else to install it if you need to be able to do development work on it too – and at that point it’s probably easier to just take a more modern approach to your Sitecore install.
In my mind, that lot adds up to strong reasons to avoid this approach. And on top of those negatives, the development landscape for Sitecore has advanced in recent years. Docker is very promising for “low effort” setup of new instances. Nuget pretty much eliminates the need to ever put binaries into source control. And tools like Azure Devops, TeamCity and Octopus Deploy make onward deployment so much simpler than it was when I first started working with Sitecore.
Hence the more modern approach is founded on these newer patterns:
- You should put only code files you write, or files you modify into source control. That ensures that when you work on upgrades, you know exactly what files you need to look at in detail.
- Structure your solutions and projects around Sitecore’s Helix principles, and SOLID practices.
- Deploy Sitecore properly onto your development machine, and publish your code on top of that Sitecore instance to run it. SIF, SIA or Docker are the best approaches these days. Pick the one that fits your situation best.
- Make your references to Sitecore and other 3rd party dependencies via Nuget rather than to local files where possible, to keep binaries out of source control. Clone times for your repositiory will be smaller, and upgrades are easier to achieve.
- Harness the power of modern build and deployment tools to compile, package and publish your work. Pick the appropriate tools to suit your organisation, and its hosting approaches. Aim for an automated pipleline that allows your QA staff to pick a build and deploy it for test without developer involvement.
Your development process will be easier. And you will be happier.
So please don’t put Sitecore in source control…