Sitecore Azure DevOps (VSTS) Build and Release Templates

November 5, 2018

Blog | Development | Sitecore Azure DevOps (VSTS) Build and Release Templates

At GeekHive, we invest a lot of time constantly improving our CI/CD process. An efficient deployment has several benefits: allows developers to promote their changes faster, avoids QA personnel from waiting on changes to be ready, and above all else means clients are spending less time and money waiting for completed code changes to go-live. Our tool of choice to check these boxes is Sitecore Azure DevOps (formerly VSTS).

Azure DevOps can serve as both a Build Server and a Deployment mechanism. Others may use a combination of Jenkins + Octopus Deploy or TeamCity + Octopus Deploy. Regardless of the exact configuration, what we feel is the most optimal philosophy is to build once, deploy many. A single build is executed, then the artifact of that build is deployed to the various environments (read: Integration, Test, QA, Production, etc.). All of our projects get the same CI/CD treatment. We’ve gotten good at setting up a full pipeline from scratch, but as the scratch part implies, there are more efficient ways to accomplish the same steps. Hence, we have created a variety of quick-start templates to reduce our setup time, SitecoreVSTS (named prior to the Azure DevOps changeover). Let’s take a look at what creating Sitecore Azure DevOps (VSTS) build and release templates entail.

Features of Sitecore Azure DevOps (VSTS) Build and Release Templates

There are many features included in the SitecoreVSTS repo. This post serves as a high-level summary of the various templates: what they are and how they are used. Our philosophy was to remove build and release scripts from the project repository to make the setup more universal and avoid collisions with project code. Ultimately, we want to avoid the question and answer of “What do these scripts do?”

Azure DevOps Build Template

The default build template json file creates the basic structure for a Sitecore build that relies on TDS. The ReadMe includes full instructions for importing the template. The template includes many GeekHive-specific options that we default to on all of our projects:

  • Download GeekHive Scripts – this optional step pulls scripts directly from the SitecoreVSTS repository in order to avoid adding them to the project repo. Exclude this step if all scripts are included in the project repository.
  • TDS – We primarily use TDS for item serialization, build output and Update Packages.
  • GitDeltaDeploy – The template includes parameters for enabling GitDeltaDeploy, though it is optional.
  • Remove Files from TDS Packages – This task strips all *.DLL’s from any Update Packages generated by TDS. This step provides the most benefit when utilizing the Synchronous Install pattern for TDS. However, even non-synchronous installs can benefit by not including DLLs in the webroot– thus preventing a soft recycle.

Every piece of the default build template is configurable: add or remove steps as needed, update variables, update parameters as-needed.

Azure DevOps Task Groups

Azure DevOps has a concept of Task Groups. These can be imported and exported similarly to build templates. The name suggests that they are used to group multiple tasks into a single task, yet this is doing it a disservice. Task Groups can (and should) be used for single tasks as well. They provide a way of abstracting the task-specific details to a shared location. For example, to intelligently recycle an app pool requires the execution of a PowerShell script. Instead of requiring that each deployment definition point to the proper script (copy/pasted from other releases), only feed the task the app pool name.


Task Group:

The Task Group (Smart App Pool Recycle screenshot above) is exposed in all release pipelines, search and add them, in the same manner, you would add a Marketplace module. Notice that the only required field is the AppPoolName. This same concept applies for all Task Groups in SitecoreVSTS.

The SitecoreVSTS repository is designed to be holistic and backward compatible, thus many Task Groups depend on one another. For example, if SPD is to be used for item promotion all dependent files and scripts are included. The following Task Groups work together to provide full SPD functionality:

  • Copy .Net X.X SPD Scripts
    • Copy SPD files (web page, config, DLLs) required for SPD to function
  • Copy Update Packages for SPD
    • Copy Update Packages to the proper location for consumption by SPD
  • RunInstallUrl
    • Install all Update Packages in an asynchronous/polling method. Issue a success flag only when all packages have been installed.

When used in conjunction, they rely on the same referenced paths and thus work out of the box. However, each piece can be removed, updated or replaced with a separate task as desired.

Usage Beyond Azure DevOps

When you look beneath the surface of the Azure DevOps-specific features, the underlying logic relies considerably on PowerShell. PowerShell scripts can be executed on a variety of build and release platforms (Jenkins, TeamCity, Octopus Deploy, etc.), indicating that all CI/CD processes can benefit from pieces of this repo. For non-Azure DevOps implementations, the Scripts folder in the repo contains all scripts that are executed as part of Azure DevOps-specific tasks.

Some of the more powerful scripts include:

  • ExecuteUrl.ps1
    • While this task can ping a specific URL, it can also perform more advanced functionality such as routing Basic Authentication and installing TDS Update Packages in an asynchronous/polling method (dependent upon the proper fork of SitecorePackageDeployer).
  • TagRepo.ps1
  • SPD
    • .Net-specific (4.5 or 4.6) iteration of SPD that supports asynchronous polling of an install. Dependent on ExecuteUrl.ps1. Essentially ExecuteUrl pings SPD on a set interval and completes once all packages have been installed.

Future Thinking on Sitecore Azure DevOps (VSTS) Build and Release Templates

This repository will be continuously updated as we discover more shortcuts and techniques in our Sitecore deployments. Currently, it is optimized for IaaS and TDS, though many of the features extend nicely to PaaS setups. All scripts have been vetted and are used on live deployments. As with all open source software, test first and implement in a way that suits your needs best.

Any Sitecore Partners relying on Azure DevOps who routinely set up CI/CD as part of their project tasks can greatly benefit from templatizing the process. Hopefully, this post inspires others to create their own templates or issue a Pull Request to the repository mentioned in this post.

Continuous Deployment should never be an after-thought, but instead, a key foundational component. The sooner it is set up, the sooner everyone on the project team will benefit.

John Rappel

.NET Practice Lead
  • Best Practices
  • Continuous Delivery
  • Sitecore

Recent Work

Check out what else we've been working on