Accepted, Not Yet Planned

Make publishing of containers default to publishing the contents individually

Currently, if you publish a publication or a structure group, you end up with a single publishing transaction. We've accepted this for years because it's "just the way Tridion works".

I would generally suggest that creating one big publish transaction is not what's wanted. In most reasonably large sites, if you published the root structure group, you'd probably break something. Common approaches usually involve deliberately breaking publish actions down to a smaller granularity. This gives you firstly some resilience against failures: you can republish only the things that failed. Secondly, assuming a finite amount of render threads, by publishing a lot of large SGs, you can easily tie up all your available threads for several minutes at a time, which means you won't be able to get your small-but-important job to publish straight away, even with high prio.

In general, I have my doubts about the usefulness of large transactions. There may once have been a theoretical possibility of transactional deployment of an entire site, but in practice this isn't a high priority for many people. My suggestion would be to make all publish actions on containers default to queuing the contents as individual items. Maybe you'd want to keep the current behaviour as a checkbox option. Maybe there'd need to be support for controlling the default setting for the checkbox.

I don't know how this would impact the content delivery side. At first sight, you'd imagine that smaller transactions would have less collisions/rollbacks/retries.

Dominic Cronin
Parents

  • "Perhaps historical data might be a separate idea to know what might fail for some reason."

    This reminds me of build history in Jenkins. Each task keeps track of the last X number of build jobs (five or so), with how long each step took, who or what triggered it, success/failure, etc. It can use the history of previous builds to estimate how long the next build will take.

    Tridion publishing tracks much of the same kind of metadata, but from the UI side, it doesn't show a history of anything before the last publish.

    On a loosely related note, one of the most important features for our users whenever anything is incorrectly published, is to know who, when, and what. Once an issue is discovered, corrected, and republished, it is then too late to do a post-morten to find out who caused the problem by publishing something incorrect and when it happened, because the publish queue has updated to show the subsequent publish.

Comment

  • "Perhaps historical data might be a separate idea to know what might fail for some reason."

    This reminds me of build history in Jenkins. Each task keeps track of the last X number of build jobs (five or so), with how long each step took, who or what triggered it, success/failure, etc. It can use the history of previous builds to estimate how long the next build will take.

    Tridion publishing tracks much of the same kind of metadata, but from the UI side, it doesn't show a history of anything before the last publish.

    On a loosely related note, one of the most important features for our users whenever anything is incorrectly published, is to know who, when, and what. Once an issue is discovered, corrected, and republished, it is then too late to do a post-morten to find out who caused the problem by publishing something incorrect and when it happened, because the publish queue has updated to show the subsequent publish.

Children
No Data