Uhm…maybe next month.
I like new things.
I like to see the things we develop as soon as it’s built.
Or sooner.
Waiting a month is not Ok Computer so if you still deploy manually, you’re doing it wrong.
If you want to get started with automated builds etc, there’s plenty of blogs out there.
This post will focus on getting Sitecore deployed to Azure PaaS.
Sitecore consists of several parts.
In a standard project you will have your Sitecore base setup which is the packages you download from dev.
sitecore.
net.
On top of that you would deploy your own customizations.
The ongoing refactoring of the Sitecore platform currently adds some “micro services” such IdentityServer, Universal Tracker and the XConnect, these adds to the complexity of deploying and upgrading your complete solution.
For today, I’ll focus on the part that probably is mostly updated during a project, the CM and CD code.
This is how we do it.
Our primary tools are TeamCity and Octopus Deploy.
TeamCity is generating our Nugets, which includes our customizations, css, scripts et al.
These Nugets are pushed to Octopus Deploy.
So far so good.
Octopus photo by Antonella Lombardi on UnsplashWhen 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 ARMIn 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.
jsonThe deployment processHaving 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.
When all code is deployed we use a feature called “Swap with Preview”.
The main difference from a “normal” slot swap, is that when performing the final swap, the worker process isn’t restarted.
This means we can perform steps like #8 and #10, warm up, which would otherwise have been pointless.
Keep in mind that the warmup uses the same hardware resources as your production site.
Hint: you should also configure a warmup url in your applicationInitialization.
This is what Azure will use when scaling out, assuring a “warm” instance.
Step #12 and #13 concludes the deployment process, swapping the production slots with our staged slots.
The most time consuming parts are the warm ups since we crawl a lot of urls internally on the site.
Skipping that, we’d probably be faster than the fastest pipeline ????Keeping trackAs an added bonus, we can also keep track of what is deployed in each release.
Having this step automated guarantees that our Jira is up to date with reality and removes the manual process, some time forgotten.
In short, when we deploy our code to Test environment, we read the git commit log and update each Jira ticket with the GitVersion just deployed (#16).
Later on, when the same release progresses to production, we tag the code in git and automatically creates the necessary pull requests, following our GitFlow process.
In #19, the Jira version created is released.
ConclusionBy integrating our entire tool set, often starting in Jira, to Git, TeamCity and Octopus Deploy, we get a much less manual and time consuming process.
This enables us to, with very little effort, deploy all the way to production.
It can even be done by a non-technical person ????.
Jira will automatically handle notification when tickets are changed and released and even produce the release notes for us and our stakeholder.
Now there is nothing stopping you from deploying your Sitecore things daily ????Oh…Don’t forget to remove the old slots and clean up your deployment history.
Azure will not allow you to deploy when you have like a 1000 deployments or so ????.
This post was sponsored by Consid — a global Sitecore partner.
.