When should I define a new publish target?

Question

This is a follow up to Should I configure multiple publish targets to publish to multiple environments?

In that question, I asked if I should define publish targets to publish between environments. The answer was that that was not best practice. So, to follow up, when should I define a publish target other than the default "internet" target?

Answer 1

Common uses I've seen is to make the following two things easier:

1. Preview of the site before it's published where users don't have sitecore access. This preview can be used internally in the organisation to see what is about to go live. Good especially if you have limited number of editors; full details here http://getfishtank.ca/blog/2-big-improvements-to-publishing-in-sitecore-7

2. Keeping the site up when deploying: let's say you make breaking content changes - like moving global settings etc. Anything where you need new code and new content to be deployed together. With 2 publishing targets you can drop new code on one CD and publish to one target while keeping old site running on other CD and other target. Once happy you can swap.

Answer 2

You can find a great explanation with examples in this blog.

A few reasons to define additional publishing targets mentioned there:

• Traffic, geographic distribution, redundancy and other scalability considerations often demand that customers publish everything to multiple publishing targets supporting different banks of content delivery servers in a single location or multiple locations. This is probably the most common use of publishing targets.
• Publish to a pre-production publishing target for evaluation before go-live. This has some addressable challenges, such as how to publish from a non-final workflow state.
• Publish some of the managed sites to one publishing target and other sites to another. This reduces publishing time and database storage, but also has disadvantages, such as complicating content sharing, and might be hard to integrate with other approaches listed here.

The first 2 examples are the most common. I have seen both working. In case of hosting servers in different distribution centers with their own databases, or in case of using a pre-production environment where people that did not have access to the CM environment could verify changes and approve before the real go-live.

Answer 3

To make an educated decision, you need to know what publishing does and what it does not.

Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.

When you publish, Sitecore copies data from 3 tables Items, VersionedFields, UnversionedField. Copy here is not just moving bytes. It is a sophisticated process that transforms data to the form that works best for delivery. From top of my head the following transformations are performed:

• Clones are merged
• Language fallback fields are materialized
• Old Item versions are removed so only recent one is kept

But Sitecore is not just Items and Fields. Other important artifacts are not moved when you publish content. What is not included:

• xDB data
• Sitecore modules, fixes, updates
• Users and Roles (although permissions are moved as they are stored in Item Security field)
• Application Files - configuration, CSS, JS, Razor views and others
• Application Code

After content is copied, target Server receives publish:end:remote event. During this event pipeline Sitecore clears caches for affected items and pushes affected items to Search Indexes.

As you can see, publishing is an expensive process. It may be an overkill to use it if you want to have two always synchronized environments. Consider shared database or SQL Replication for that scenario.

Multiple Publishing Targets work best for scenarios when two conditions are met:

• Sitecore and your App versions are synchronized
• You need to control over how your content is traveling from one environment to another.

Steve Newstead already provided great sample when it make most sense in his answer

Answer 4

Generally we do it when we have two databases -publish and preview Commonly there are two scenarios where multiple publish targets are useful:

1. when project is in continuous development phase, we go live in every sprint. In such cases, authors can preview the site using one database where we publish our content. This is also useful when we go for localization.

2. When we want authors to validate content before going live, preview database will be useful and later while going live everything can be pushed to Publish Database.

so keeping multiple targets is useful in higher environments and mostly when we deal with multilingual sites.