I'll tell you what I have done a few times and see if maybe it helps you. But you have to balance the user's content and possible template changes with what you are going to overwrite with unicorn yml files.
Dev
In dev I track the following items in Unicorn:
- Content (/sitecore/content/siteA/*)
- Foundation, Feature, Project, Layouts, Templates, Settings, etc...
Each one of these are in their own configuration so I can sync/serialize them individually. This allows developers to share content as well as templates and all the normal Sitecore configuration items.
I find this the best use case for Unicorn and I use it all the time. Syncing content between developers is seamless with Unicorn. I recently had to sync 80,000 items several times. Easy as pie.
UAT
In our UAT (pre prod) environment, I keep the same configs. My CI will deploy all code, BUT what I do is put git on my UAT CM server and sync the repo/yml files on the server. What this gives me is that the content that is created on UAT comes back to dev and the content I created in dev gets pushed to UAT.
- CI deploy code
- Git push changes
- Git pull changes
- Unicorn sync
Stage
Stage is difficult. As a staging server, this is your chance to test your deployment before it goes to production. But as you will read below, I do not use unicorn in production for the reasons noted.
I think you have three choices
1. Don't deploy unicorn to stage or production
2. Deploy unicorn to just stage and risk your deployment untested
3. Deploy unicorn in stage and production
Whatever choice you make, you should deploy unicorn files with CI to a specific folder and transform your unicorn configurations to use that folder for the datastore. Then you can sync unicorn with PowerShell Sync-UnicornConfiguration.
Production
I never deploy Unicorn content to production. #1 with Unicorn in place, the yml files on disk are the source of data for Sitecore, not SQL. So the speed of disk is now your limiting source for CM server speed. #2 Also the risk of content being archived with a unicorn sync is high if you remove yml files in a deployment.
I also would not deployed Unicorn yml files for templates, layouts. etc.... You are much better off turning them into an installation file and installing the update traditionally.
yml to sitecore install: https://kamsar.net/index.php/2017/02/Unicorn-4-Preview-Part-2-5-Generating-Packages-with-SPE/
Sync live content back to dev
Updating dev with production is very important for proper development/uat testing so you are working with real data and not stubbed out developer content. There are several ways to get that data back. The request here is Unicorn and I will talk about some others.
Unicorn
You can configure unicorn on your CM server, but see performance concerns above. But once you serialize your content tree and media items (use LFS if you are keeping media in git). You can zip up the yml files from CM and bring them back to dev/uat. Unzip then into dev unicorn datastore folders and sync all those items right back into your de/uat environments.
RAZL
This is one of my favorite solutions for this problem. https://www.teamdevelopmentforsitecore.com/Razl RAZL is a tool that uses the built in Sitecore serialization to sync the Sitecore tree from one site to another. It's a really easy tool to you use. And you can create scripts that you can run with automation to automatically sync data from one environment to another. It's not a free tool, valuable.
Sitecore packaging
The simple solution is just to use Sitecore packaging to package up your tree and reinstall into dev/uat. To make it even easier, you can use Sitecore PowerShell extensions. That adds a [right click] > [download tree
] option to Sitecore. This makes it really easy to quickly download Sitecore content.
Database restore
This is kind of the nuclear option since it completely overwrites your dev data. But you can backup production core/master/web databases and restore them over your dev/uat databases.
