Following a conversation on the #helix-habitat channel over on Sitecore Slack Chat a few days ago, I thought it would be worth penning a quick post…
A question was asked about “How to organise your CM vs CD config in a Helix Solution”. This was about configs in your specific implementation, not the default Sitecore configs that need to be enabled or disabled for a specific Sitecore environment.
For example, you may have some specific custom pipelines or event handlers that should only run on the CM instance.
Some suggested that these custom configs should be enabled/disabled/modified as part of the deployment process using PowerShell, possibly using an XML file which provides a mapping of files for the environments. This could then be maintained by the developers.
I suggested a different approach, and “tagging” your config nodes to make them easier to patch… The approach was new/unknown to some so I thought I would (re)blog it.
Have you ever had the need to rollback your Sitecore deployments? Or maybe an upgrade went wrong and you need to rollback the changes?
Well you should’ve taken proper backups then, shouldn’t you! Learn your lesson yet? Now go back and add proper back-up steps to your deploy process… Good. Jeez. Shortest blog post ever! Moving on…
The problem with backups is it takes time, which seems to exponentially increase as your Sitecore database increased in size, and an equally heap load of time when you need to restore that database. The other problem with the backup is that it is just a point of time restore, what about changes that have happened since that backup had taken place?
I’ve recently been spending some time to upgrade our solution as well as perform some tweaks, optimizations and clean up on our deployment process. Even though I am the creator of UniCorn, I’ve almost exclusively been using Team Development for Sitecore in all the projects which I have worked on 🐘
The release of TDS 5.5 allowed developers to add their own custom deploy steps. Previously these might have been conducted manually (urgh!) or we had deployment steps added to our process in Octopus Deploy to conduct these. The post deploy steps however are better since they can be developer controlled and added to source control. Win!
The Hedgehog Team has been asking for the community to share their post deploy scripts. You can find a number of scripts here. There are some great scripts there, similar to what we currently have. But the way that script are added and managed in the TDS projects was a bit annoying to me…
So it got me thinking about that great quote by J.R.R. Tolkien:
One Script to rule them all, One Script to find them,
One Script to bring them all and using SPE bind them
Have you ever had to create a lot of users in Sitecore? Maybe you are setting up a new Content Management server and the users will be managed in Sitecore and you have to set up all the new users? Or maybe you need to create a whole bunch of users for the testers to be able to check different types of functionality for different user roles? Or maybe conduct some performance testing?
All of the above was true for us and rather than going Sitecore > Security Tools > User Manager > New then type, type, type and click, click, click, we headed for SiteCore PowerShell Extension. Cos…