Jeremy Davis
Sitecore, C# and web development
I came across an interesting issue generating a Sitecore Package recently. Googling the issue didn't give me the whole answer, so it's time to enhance the internet again with a explanation of what I saw and why I think it happened...
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.
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 on from previous discussions about packages and their definitions, I found myself needing to quickly merge together the definitions of two different packages recently. And that sounded like an opportunity for a simple tool to add to my collection.
Having looked at all the pipeline components for package generation last week, now it's time for a wrap up for this series.
As I mentioned in one of the earlier posts, as I worked through the code for this prototype, I changed my mind a bit on some of the basic architecture for the core program from the first post. I ended up re-working the configuration from the original idea and making the source control input and package saving output into configurable options.
In last week's entry I listed out the set of pipeline components required to generate a package. This week, lets have a look at what goes into each of those components and see how they interact with the configuration and source control data.
In the first two posts in this series we've looked at commandline parameters and fetching data, and then saving package files. This week, we'll look at how the fetched data can be transformed into the package data.
After last week's initial thoughts I've been beavering away on my prototype, and now have a working version. Which is good, as this series of blog posts wasn't going anywhere useful without that...
So this week I'll address the issue of how you can save XML for a package definition without having any references to Sitecore's DLLs.
Recently I posted an idea for a PowerShell script to extract the set of changed items in TFS needing deployment for a Sitecore project. I left the script at the stage where it gave a list of the files to package, but didn't actually give you a package definition.
Having done a bit more thinking about how that might be achieved, I've decided that it's probably worth a series of posts as creating a sensible solution to the problem seems a bit too complex for a script and a single post.
So for this first post, I'll sketch out the problem I want to solve and look at some of the basic code if will require. I'll flesh out the code an implementation over the rest of the posts – but I'm not sure how many there will be at this point...
