According to it’s documentation, Sitecore Publishing Service is a faster, more reliable and consistent alternative to the existing Sitecore publishing methods, and this is specially true when you are dealing with a large volume of items; it also provides better user experience and logging information through the (also included) Publishing Dashboard.
The service consists of two components:
Publishing Service: this service runs on a separate process to your Sitecore instance, it is a .NET Core application and it is the one responsible for actually running the publishing process by queuing and executing jobs, transferring items in bulk from source into target databases directly, provide information back to the user by sending logging information to the Dashboard, etc.
Publishing Service Sitecore Module: this is a Sitecore package that you will need to install on your Sitecore instance, it will provide the user interface (replacing the default publishing UI) and the Publishing Dashboard. Its job is to forward all the publishing actions to the Publishing Service and also to provide visual feedback and logging about the state of the publishing system.
The following diagram represents how the different actors in this process interact with each other:
As you can see, there are a couple of concepts associated to this process, lets take a look at some of them:
Publishing jobs: with the new service, all your publishing requests are encapsulated as a “publishing job” and added to a queue for processing.
Manifests: when a publishing job is started, the first thing the service will do is to calculate the manifest, it contains all the task the job will perform, for example, deciding which items are publishable or not, each publishing target will have it’s own manifest, so there could be more than one manifest involved int the job.
Promotion: it is the process of moving items and data from source to targets.
Manifest results: tracks all the changes made during the promotion of the manifest; the manifest result will be created only if any change was made in the targets.
The key advantages I saw while trying this new service were, first, it really improves the performance of publishing process not only from our master to our web database but also when publishing to Content Delivery servers (we will see some tests results about that in a later post). And second, from the user usability perspective, it solve the standard publishing service annoying publishing dialog that remains open while the publishing process is running because now, our publishing requests, will be encapsulated in a publishing jobs that will be queue for later processing by the Publishing Service (which runs in a separate process).
So far I’ve seen only one disadvantage, at least it is for me, and it is related with the UI; when you are publishing from the Content Editor, you don’t have the option to do a “repair” which you do have when publishing from the Publishing Dashboard, but from the Publishing Dashboard you can only publish the entire site, so there is no way of doing a “repair” for a selected item.