Sitecore deployment: A look at its anatomy

By: Sitecore MVP Jason St-Cyr

Valtech
Valtech — Sitecore experts since 2008
3 min readJul 4, 2016

--

Preparing to deploy your Sitecore instance? Following along with these four phases will help you to develop a plan and put you on a path to successful deployment.

Here is a brief overview of how an automated deployment for Sitecore comes together. This should help you get started with planning out your deployment strategy.

1. The ‘compile’ phase

During the first stage of an automated deployment, standard MSBUILD technology is used to perform a compilation of the .NET solution stored in source control. This will generate the following:

  • A website folder that can be deployed to environments
  • DLLs placed in the bin folder for each .NET project or referenced third-party DLL
  • Assets (CSS, JS, ASCX) used by the website for presentation
  • Configuration files (App_Config) that contain the solution configuration for the Sitecore instance

2. The ‘content’ phase

In addition to standard .NET projects, Sitecore projects also have content that needs to be deployed. nonlinear makes use of Team Development for Sitecore (TDS) projects to source control content that is critical to the operation of the solution. These elements will include Sitecore data templates, Sitecore presentation details, system configurations, customized rules, and other elements which are stored in the Sitecore database but are not business-authored content for the website.

A very simple example would be the field definitions for which fields are available for an author when editing the titles (browser/navigation/page title) on a web page.

The MSBUILD step is also used to build or deploy content packages using these TDS projects. During this phase the build server will trigger the following:

  • The Build server installs necessary TDS web service if missing
  • The Build server opens a connection to the TDS web service on the configured endpoint
  • The Build server begins transmitting serialized versions of these items to the target Sitecore instance
  • The Sitecore instance then saves these to the Sitecore database

If you are using a tool like Octopus Deploy, this phase may be broken into separate steps of building packages and then said packages.

3. The ‘file’ phase

After the code has been compiled into a package and the content has been transmitted, the build server can begin deploying the compiled fileset package to the target servers. This usually involves multiple steps:

  • Clean-up of any files on the destination server that should be removed prior to deployment- this is usually contained to the Sitecore App_Config\Include folder, and only files with certain naming conventions that identify them as part of the nonlinear solution will be removed.
  • Deployment of all files to the destination server(s).
  • Renaming of configuration files- this ensures that any environment-specific files are installed and activated. By default, these files are set as ‘.disabled’ or ‘.example’, and must be activated based on the requirements of the instance.

4. The ‘publish’ phase

After the release has been deployed, it is necessary to ensure that the content in the Master database is pushed to the delivery databases. This requires remotely triggering a publish in the Sitecore instance.

It is useful to use an HTTP API for this phase, which the build server will trigger in order to begin the publishing phase. Depending on the performance of the environment, it may be necessary to trigger a ‘wake-up’ of the instance prior to publishing in order to ensure Sitecore is ready to receive the publishing request.

The ‘optional’ steps

In some cases, not all required deployment components can be automated. In these cases, specific manual steps are provided which must be executed during the deployment to ensure a functioning site. For example, it is against most security best practices to automate the deployment of users from one environment to another.

You will likely wish to remove as many of these manual steps as possible to ensure a smoother and more repeatable process.

If you enjoyed this post, be sure to visit over the next few weeks as we’ll be featuring a number of posts that identify the crucial elements of Sitecore deployments. Need some help with your own Sitecore deployment? Get in touch and we’ll get you up and running in no time.

Looking for more Sitecore insights? Visit nonlinearcreations.com

--

--

Valtech
Valtech — Sitecore experts since 2008

Valtech is a full-service digital agency. Our staff of 2,500 operates from 36 offices around the world.