Sitecore Deployer

While working with Sitecore deployments based on ARM and PowerShell scripts, developed by Rob Habraken (Rob has covered them in a series of blog posts on his own blog) and optimized by me, I noticed that we are having a problem: these scripts are used on a per-project basis and once implemented, they start aging. Since manually updating scripts for each project is a dull and cumbersome task, it usually is never executed. So I decided to build a VSTS release task, which could be reused in each of our projects and makes it easier to always have the latest version of the ARM and PowerShell scripts for a certain Sitecore version.

How it works

You can check the PowerShell script at my repository.

This extension uses a VSTS connection endpoint to authorize against Azure and will take the following input:

• ARM template path
  The ARM template published by the artifact source. Usually, it is a build.
  ARM parameters path
  The ARM parameters file for the template, published by the artifact source. They will be parsed at runtime and, in case of the ‘Deploy’ deployment type, combined with the output of the ‘Infrastructure’ deployment type and fed into template.

• Resource group name
  The name of the targeted resource group, where the resources will reside. If the deployment type is ‘Infrastructure’ and the resource group doesn’t exist, the script will attempt to create it, but for the deployment type ‘Deploy’ it will throw an error.

• Location
  A dropdown with the available locations for your resources.

• Deployment type
  There are several differences between deployment types: the ‘Infrastructure’ deployment type will attempt to create the resource group if it doesn’t exist and provision the infrastructure, while the ‘Deploy’ deployment type will get the output of the ‘Infrastructure’ deployment type and combine it with the parameters in the template parameters file to deploy the application.

• Generate SAS?
  If this is set to Yes, then the script will try to generate a short-lived SAS for the SCWDP packages, passed in the parameters. The storage account must belong to the same subscription where we are deploying to. If it is not possible to generate a SAS, it will silently continue. If the license.xml file has to be retrieved from a URL and if it is stored on a storage account which belongs to the current subscription, the script will try to generate a SAS for it as well.

• License location
  A dropdown which allows you to select how the license will be passed to the Sitecore installation. It could be a URL or be specified inline (e.g. copy-paste from the actual file into the field, or, which is more secure, store the value in a protected build variable and add a reference to it here). But it could also be a reference to the file system (published as an artifact of a build), and finally, you can say that your license.xml file is pasted as a parameter into your template parameter file.

Section “Security”

It is advised to deny access to the Processing role for everyone and allow access to the Reporting role for Azure only. Also, I checked with Sitecore and by default you do not need to deploy any custom code to these roles, which can speed up your deployment greatly. So, those checkboxes are needed only in case you are not deploying your own custom code on the Processing and Reporting roles and you are not running in ASE (as ASE allows to deploy additional firewalls in front of your web application).

• Limit access to PRC role by IP
  This one is a “catchy” setting. If you will check Sitecore templates and SCWDP packages from 8.2 till 9.0.1, you’ll notice that in all fully-fledged deployments you are allowed to set a client IP and client IP mask to limit access to the CM and PRC instances. MsDeploy (SCWDP) packages will have a field for it. By default, it is 0.0.0.0/0.0.0.0. Problem is, this parameter allows you to specify one, and only one IP, which is weird, because you’ll need at least two: 127.0.0.1 to allow applicationInitialization, fired by the Web app itself to complete initialization correctly, and your own IP to access the CM. IP and mask, specified in the relevant parameters, will be passed to the web.config and will be written in the section . And here comes another catch, because the section is defined as follows: “”, and this “clear” node removes any rules defined on the web app in the Networking section of the Azure Web app. So, the only possible solution to protect the PRC web app with only default SCWDP packages deployed (like PRC role + modules) is to inject the parameters IP 127.0.0.1 and mask 255.255.255.255. This will effectively deploy the same limitation on the CM web app, but, at the end, normally you are deploying your own set of config files on the CM instance anyway.

• Limit access to REP role by IP
  Following Sitecore best practices, it is recommended to limit access to reporting role by IP, allowing only Azure IPs. However, I see it as this: we need to allow access to reporting role from other roles of deployed solution (CM, CD, PRC) and, possibly, from our own IP(s). Enabling this checkbox will:
  a) show additional control for entering IP/Mask in comma-separated string
  b) on execution of script – all outgoing IP addresses of other roles will be added to allow list (along with 127.0.0.1 and anything entered in additional control)
  Since the REP SCWDP package does not have ipSecurity embedded, this works flawlessly: IP based limitation will be deployed on web app level (you can see it in the Networking section of the Azure web app).

That’s all I wanted to describe about this new extension. Feel free to contact me for additional questions, push PRs and discuss it on the repository.