I try never to write about SDL Tridion related topics and whilst it is useful to the SDL Tridion Community, I want to write about other things. However, it has been too long since I have written and I had to do something soon… so here I am again and I decided to look into publishing with SDL Tridion.
What is publishing?
In short, Publishing is the mechanism SDL Tridion uses to put content on a presentation environment. Content and Templates are rendered together and HTML, XML, JSP etc. comes out the other side. When you chose to publish something, you start a chain reaction that sees your content successfully published on your website. During that process SDL Tridion makes sure all your dependencies are taken care of. That single item you chose to publish might lead to a few more items being published so that the website has no errors or inconsistencies in the content.
There are a number of factors that influence how publishing behaves and how you, as a user, can get along with it. The basic factors are:
- The implementation
- The content
- The hardware
So what do we want from publishing?
Mostly you want content there as soon as possible so you can move onto the next task. However, there are allot of other people doing the same thing and on large scale environments or environments with challenges on performance you might have to queue up.
So what can you do?
You need to publish content in a way that ensures the least stress and maximizes the available time for publishing. So I have gathered here some tips that might help you.
Publish Structure Groups
When you publish anything in SDL Tridion, the number of items you select in the Content Management Explorer equals the number of jobs in the publishing queue. Each job in the queue must be completed separately and therefore has all the overhead of being treated as a separate job. However, if you want to publish allot of pages, for example; part of your site, then it makes sense to publish the Structure Group rather than all the individual pages. It will take just as long to get the task done, just with less overhead. If you are worried about failures then use the failure tolerance setting on the Advanced tab of the publishing dialog.
Use priority publishing
Most users have found the priority option in the publishing dialog. It allows you to change the standard priority to change how the publisher will pick up your publishing job. High = it goes first, Low = it goes last. Normal is everything in between. Using Low priority is handy to be able to use the available publishing time of your servers without getting in the way of normal work. So for example, you need to roll out a future site to Staging; then use low priority publishing. It will get there as soon as the publishers have time to deal with it.
Publish on off peak hours
I looked at the number of items published per day for one of my customers recently. It went like this.
- Wednesday: 16952
- Thursday: 21829
- Friday: 13279
- Saturday: 1
- Sunday: 14
- Monday: 1527
- Tuesday: 2681
- Wednesday: 357
Notice anything? Many items that could have been published were not because they did not use the weekend. The servers were not turned off; they sat there wasting that publishing time for nothing. So, scheduling a task for the weekend (or even evening) could make better use of the time available.
Publish to staging or live but not to both
Too often I see publishing jobs in a queue that are the same item but going to two different places and those two places are often Staging and Live. The staging site does need to be up to date, but Live is much more important and the process should be that once you are satisfied with your content you publish it to live, so why republish it to staging? If you must publish to staging then make it low priority or maybe schedule a complete republish to Staging in the weekend (see above). To enable low priority publishing all the time you can set the default priority to low on a Publication Target. That way all jobs going to Staging would be low priority and you never need to remember to set it.
Check the details of what you are about to publish
Before you publish, take a look at what will publish and make sure it is what you expect. You can do this using the “See items to Publish” button in the bottom left of the publishing dialog.
Plan your roll outs
When rolling out websites, plan how you are going to do it and leave enough time to get everything done without impacting regular business.
A watched pot never boils
Refreshing the publishing queue frequently might give us the satisfaction that we know that the job was completed as soon as its status is changed to “success”, but in reality it does not make the job go quicker. You might also want to change the filtering options so you only see your own successful tasks. And do not forget, if it is in the queue, it will get published; it just has to wait its turn.
Use priority publishing. Great tip! but….
… well everyone thinks their own job is more important than someone else’s. It’s very tempting for people to use high priority, but that just ends up in a tragedy of the commons.
I usually advise people to choose between low and normal. When the chief executive’s latest blog post /has/ to go on the site /now/ the chief editor or the sysadmin can use high to get it there. If everyone else has queued their own jobs as high, the sysadmin’s only resort will be to delete their publish jobs. (Yes – sysadmins can do that.)
Or maybe you’ll end up with the chief executive standing next to your desk!
So please everybody – try to think of “high” as jumping the queue. We could all do it, but generally we don’t and life’s better for it.
High priority publishing can be a blessing though. And if/when other people use it too often, just write a simple piece of event code to demote any inappropriate high prio publish task.
Hi Julian, This is a great post. Another useful item to add is the ‘rollback on failure’, as many customers feel they don’t want to publish when a techy isn’t around, and this really should give them some peace of mind.
Great post, some of which has made its way into the product documentation for our next release.
Good post.
One of the key enhancements we have put in place is to make the default publish priority for staging to “Low” and Live to “Normal”.
With regard to publishing structure groups, I don’t quite agree. In theory, I love publishing structure groups since the dependent objects are all gathered into a single package for deployment, rather than sending the dependencies over and over again for each page.
However, in practice, publishing a structure group becomes a roadblock. If you have two publishing threads and two structure groups publishing (even on low priority), all subsequent publish transactions (even those on High), will have to wait until a thread frees up. Publishing individual pages at least will allow the interleaving of higher-priority transactions. Encouraging our users to do this has made them all a bit happier with each other.
Good point on the structure groups – that clarifies a con of using publishing, SG publishing has pros and cons but the crucial point would be that changing your behavior can influence your experience of publishing. But indeed publishing structure groups could change other peoples experience of publishing while you are publishing your structure group. Use with care 🙂