Deploying to a Sitecore environment safely and seamlessly can be challenging. The main reason for this is the amount of time it takes to deploy item updates. While code changes are pushed very rapidly, pushing updates to the content delivery servers is usually done via a publish operation. Depending on the number of changes, this publishing may take a long time. While this is going on, your site may experience problems due to inconsistencies between items that have been deployed and items that are waiting to be deployed. In addition, the items needed by the newly deployed code may not be available yet.

There are a number of strategies that have been developed to prevent this from being a problem in large production sites. These work well, but are beyond the scope of this post. I would like to cover a deployment process that uses the Sitecore Azure platform and TDS to seamlessly deploy a site.

Sitecore Azure allows the Content Management and Content Delivery servers to be hosted in the cloud. This allows the deployment of a robust Sitecore infrastructure with a minimal amount of physical hardware. You will still need to host a Deployment Server (DS) locally, but this hardware is usually a low-cost off the shelf server or even a VM.

To perform a deployment to Sitecore Azure with little to no interruption, you must configure the Content Delivery servers to use separate databases between the production and staging Content Delivery instances. This is done by unchecking the “Share databases between the Production and Staging slot” checkbox.

By choosing this configuration, there will be an additional database in the farm for the staging instance. This configuration allows the production farm to run while the staging instance is being upgraded and tested. This should allow the deployment of updates to the instance with little to no disruption of the site.

Once the servers have been setup in Azure, the farm should resemble the diagram below.

Building the solution

TDS is used to build the solution and deploy it to the Local Deployment server. As part of the same build, TDS is also instructed to build an update package. Normally, TDS builds to either a Sitecore instance or a package for later deployment. Due to the nature of Sitecore’s Azure implementation, having an automatic deployment and package in a single build is very useful. This allows the site to be deployed and tested locally before beginning the Azure deployment. In addition to enabling package generation, the option “Generate separate code and item packages” should be chosen for this build as well.

The item update package generated during the build will be used later in the deployment process. The code update package will be discarded.

Content Management Deployment

The deployment process to the Content Management server takes place in two steps. First, use Sitecore Azure to build and deploy a new code package to the Content Management farm. This pushes all code changes TDS deployed during the build to the Sitecore Azure Content Management. Next, use the update installation wizard on the Azure Content Management to install only the item package generated during the build.

At this point, all code and items are deployed to the Content Management environment and the users can test the site and complete any content changes before going live. Users should be warned that they cannot publish changes to the current live site at this time because they may be incompatible with the version of the site running on the production Content Delivery farm. Updating permissions on the publishing targets to hide the current production instance in Sitecore can be used to prevent users from accidentally publishing at this time.

Content Delivery Deployment

When testing on the Content Management servers is complete, the Local Deployment Server can be used to build and deploy a code package to the staging instance of the Content Delivery farm(s). At the same time, the latest version of the Content Management content should be published to the staging instance of the Content Delivery database. Once both of these operations are complete, testing can begin on the staging instance.

The production instance of the Content Delivery farm is still running the old version of the site, using an old version of the Sitecore items. The staging instance is running a new version of the site, using new versions of the Sitecore items. When testing is complete, the new site can be deployed by swapping the production and staging instances using the Sitecore Azure desktop application. Within a few minutes, the new site will be served off the new instances.

Publishing Targets on the Content Management server

The names Sitecore Azure gives the publishing target databases are not very user friendly. The Display Name of the publishing target item can be set in the Content Editor on the Content Management instance to a name like “Production” that is much more meaningful to your users. The publish dialogs will show the friendly display name instead of the internal names. This has the added advantage that when a new version of the site is deployed, the proper Content Delivery web database can be given a name the content editors will be familiar with. This prevents content editors from publishing to the wrong location.

Going Further

In the process I have outlined, there are many manual steps. Since most of the interactions with Azure are done through the Sitecore Azure Desktop application, there is ample opportunity for automation. Scripting these steps can be accomplished by adding web services to the Local Deploy instance to programmatically execute these steps. This is beyond the scope of this post. When adding additional automation to the process, some consideration should be taken to preserve the built in opportunities for testing the new deployment. Even though there seems to be a lot of testing, this careful attention to detail helps ensure a successful deployment.

As with any deployment, the developers are responsible for creating and testing a backup of the existing site. Sitecore Azure provides a relatively robust platform at a good price, but the developers are responsible for managing the backup process. Covering Sitecore Azure backup strategies is beyond the scope of this document.