When it comes to deploying the Nugets, there are some things to keep in mind:

Deploy to all environments the same way. Consistency is key. Use the same Nuget package for the entire life cycle f.ex. development or test/production — only configuration variables differs.

In our case this means we deploy our git branch dev every time a pull request is approved and merged (you use pull requests, right?). For the test/production we build from the standard GitFlow branches, hotfix and release . In Octopus this is done using channels with different rules for “pre-release tag”.

Brothers in ARM

In today’s solutions, infrastructure can be described using code. In our case we use Azure ARM templates which is also what Sitecore provides as a “starter kit”. The starter kit provides an quick way of deploying a standard setup of Sitecore to Azure. This comes in different flavors and sizes but usually you would need to tweak the setup post-deployment. For example you might want to use an Elastic Pool for the SQL Server and you probably want to change the CM/CD web apps to better fit your needs.

For those not familiar with Azures ARM templates, they are JSON based and describes instructions and definitions of which resources are needed, how they depend on each other, and which applications should be deployed where.

The Sitecore provided templates are in my opinion only used for the initial provisioning. During a new project you probably do deployments everyday. Hopefully this is also something that will continue, if not daily but as often as possible, all the way to production during the lifetime of an application. It’s time to break free from the good old quarterly releases 😏.

To support this, we created a stripped down version of the ARM templates and repackaged the web deploy packages. It’s all described by Rob Habraken here.

Our setup is using Octopus Deploy and is hence a little different.

In our build process we produce two artifacts, the Sitecore customization and a Azure Nuget package used for deployment.

ARM consist of one (at least) resource file and one parameters file. Our parameters file contains the dynamic variables, which differs between each environment. The variables are managed within Octopus Deploy. Octopus provides really good functionality around variables, and scoping of values for environments, channels and more.

Since we do blue/green deployments using Azure Slots, the infrastructure during our continuous deployments are described as below. Note this is only a subset of the resources but shows the slots setup which is the most important part.

Stripped down infrastructure.json

The deployment process

Having all the prerequisites ready its time to deploy.

You should have one Nuget with your customization and one Nuget with the Azure package used only for deployments. In Octopus Deploy, you first deployment the Sitecore baseline, #1. This is the step using your ARM templates described above. It will use the templates to verify your infrastructure, create the slots as seen above, and finally deploy the stripped down Sitecore baseline package. The ARM templates knows how to deploy and the parameter file contains urls to the packages containing Sitecore base.

Step #2 and #3 will run in parallel, deploying our custom code to the newly created, fresh web app slots. Again, we’re using the same variables used in the azure parameter file, enabling us to deploy to different Azure subscription and different environments.