I'm in the middle of preparing a talk for an upcoming Sitecore user group on the subject of using PowerShell DSC for Sitecore installs. (I'll post a write up of the talk after I've given it) And one of the things I've discovered is that once you get into the guts of it, using configuration variables alongside Script Resources can be a bit confusing.
So, for the benefit of my future self (I'm bound to forget this as I am taking time off from my preparation to head over to the US for this**1 and this**2 ) I'm writing down what I've worked out...
As I slowly get to move from v6.6 era versions of Sitecore onto the more modern releases, one of the topics I've been re-visiting is install automation. In the past I'd looked at PowerShell scripts for installing Sitecore itself, and configuring development sites, but one of the new things to deal with once you move past v7.5 is the need for MongoDB. Turns out, that's pretty easy to automate if you need to:
I came across an interesting approach for improving the performance of
automated package installs
the other day. In the space of one day of internet reading I saw the
Sitecore.Data.BulkUpdateContext
class mentioned
in a blog post
and it came up in MVP forum discussions. In both cases, it was mentioned in the context of making item operations faster. Hence it seemed like an interesting thing to investigate, to see what sort of difference it would make to my previous work.
Another helpful addition to the "scripted installs" functions I've been looking at for the last few weeks is the ability to trigger a full rebuild of a search index. Last week we looked at deferring the indexing of items installed by a package to try and help speed up the scripted install of packages. So it makes sense to be able to trigger a build as well...
Last week I looked at some simple PowerShell script to automate installing packages into Sitecore instances. Having spent a bit of time testing this process, I found a couple of useful tips for speeding it up:
After you've finished installing an instance of Sitecore for development or test (as I've been discussing in my previous few posts – Installing, Adding DMS, Hosts & SSL), chances are you'll need to deploy some modules or packages onto it. Things like Web Forms for Marketers are regularly needed as a basis for development work. So what can you do if you'd like to automate this with PowerShell as well?
Continuing my current theme of installation automation via PowerShell, the next task I found myself looking at was how to enable Sitecore's analytics for a newly installed Sitecore instance. This is a task that the standard .exe installer doesn't do for the v6.6 sites I'm working with, but is relatively simple to automate.
Ages back I wrote up some
work on automating the Sitecore installer. I noted back then that I wasn't sure what the purpose of the
SC_IISSITE_ID
parameter to the MSI was. Having done some more work on the topic of install automation recently, I've got some more detail on what it's for now, as well as another parameter that's more important than I had realised...
When you install an instance of Sitecore via the .exe installer you get a single host name added to your machine, which matches the instance name you chose. But for real world projects this is rarely enough. Most websites need to respond to other host names, and they often also need SSL certificates installed so that these hosts can be accessed via HTTPS. Developers need these features set up so that they can code and test with them.
Recently I've been looking at automating more installation tasks via PowerShell, in order to try and standardise the processes developers use when setting up new instances for work. I've been digging out helpful bits of script from across the internet, and I plan to write a few posts to document some of the approaches I've been experimenting with. The first of these posts covers info on automating host names and their bindings:
Quick bit of script this week. Ages back I wrote up the process for working out how to run unattended installations of Sitecore using its .exe installer and then converted that to PowerShell. Recently I've been doing a bit more work on install automations in PowerShell. (Which I plan to write up in future posts) But while doing this, I realised that the flip side of automating the install is that it's also helpful to be able to remove an instance of Sitecore automatically too...