By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Sitecore deployment can often strike fear into inexperienced developers for a variety of reasons, but often it’s down to two core issues. Firstly, the unknowns of a deployment can be daunting if they haven’t been in control of the entire development. Secondly, the anxiety that comes from wondering what happens if it goes wrong?
I have shared these concerns just like any developer, but after working on a wide range of projects and for a Sitecore Platinum Partner I’ve gained a repertoire of tips and techniques that are worth sharing. So, if the thought of Sitecore deployments makes you nervous, here’s some key points for you to use to help minimise risk.
Despite the growing popularity of automation, there are still sites and Sitecore deployment processes which have several manual steps. Ironing these manual stages out alleviates the pain points that are easy to be made when doing these steps.
It’s important to choose the right tools and to get your CI (continuous integration) setup running smoothly. Granted each project will have its own quirks, but in the main each project should run through the same CI process.
At UNRVLD we have used multiple tools to form our CI process:
However, there has been a shift lately to VSTS (Visual Studio Team Services).
VSTS provides a single platform to allow us to run our entire CI process, instead of using multiple toolsets to achieve the same result. At first there was apprehension because we’re comfortable with TeamCity and Octopus Deploy.
It’s been our bread and butter for years, so you can understand the nervousness to move. With a few POC’s (proof of concept) under our belt and we are slowly migrating over to VSTS. It gives us one consolidated view of what a release contains and the status of that release, not to mention the reporting capabilities if offers.
Sitecore items can be a headache when it comes to deployments and there are many questions to consider, including:
Again, there are multiple tools to choose from, such as Hedgehog TDS or Unicorn. We run Hedgehog TDS as it provides the ability to synchronise Sitecore items via our IDE. This allows us to create update packages for deployments.
Sitecore Ship then allows for the deployment of these Sitecore items to any environment as part of the CI deployment process. Without this, it’s the traditional Sitecore package management option for the installation of Sitecore items.
I’d advise against deploying content, as typically you would not automate the deployment of any Sitecore content. By that I mean anything that would be generated by a content editor for the end users’ readability.
Why? Well, only the customer creates content, they usually have teams of content editors doing this on the live site. If we are to deploy content which has been entered in a development or UAT environment, then the chances are it is test content.
So, what do we deploy?
We deploy:
Sitecore, especially in a production environment is scaled and has multiple roles. These can be app services, physical servers or VMs.
These roles need to be considered when it comes to deployments. Deploying the wrong configuration, to the wrong role could have huge impacts on things such as indexing, analytics, email campaign management. So, it’s well worth spending the time getting it right and spending time ensuring your configuration transforms are transformed. This also mean making sure they’re transformed correctly for the relevant role.
It’s not straight forward and can consume a fair amount of time, especially in a scaled environment with multiple servers or services. But overall, it’s a worthwhile investment of time, so get in touch if you’d like to talk about this in more detail – we’re happy to help.
This is as important as the deployment itself. If the deployment goes wrong you’ll need to be able to recover from it, and to recover from it you need to have a plan.
This is a crucial part of working towards a painless Sitecore deployment because If you don’t have a plan, then the chances are you will be in a position where the rollback cannot be fully completed, or certainly not without a lot of hassle that’ll result in coming out of the other side praying that you won’t have another deployment any time soon.
Key things to consider
In a perfect world, the entire rollback could be performed by the CI process, but we all know the perfect world is not always realistic. If your CI process doesn’t have a rollback plan configured, then ensuring you perform the following steps will help:
A common quote often heard from customers is, “we can’t have downtime or if so, we need to do it out of hours”. With that in mind we solve this problem with a few different approaches.
The load balancer approach
Most production environments will be scaled so that they are fronted by a load balancer which manages the traffic between the multiple servers that sit behind it. You can use this to your advantage during deployment time. It’s possible to take one of your servers out of the load balancer, so that traffic is not being pushed to it. This technique allows you to perform and test changes on that server without affecting the live site.
The parallel instance or blue green deployments
In this option you could duplicate an instance of the site for deployment time only, this allows the current live instance to continue running whilst you deploy to the newly created instance. Doing this allows you to test it prior to making it live by re-pointing the domains at the new instance.
If you are running app services on the Azure platform, then you have the ability to utilise deployment slots. This is similar to running a parallel instance as I described above.
It allows you to deploy your application to a slot, which then gives you the ability to test your application. Once it is signed off you can swap instances with zero downtime as your application will continue to serve the old site whilst Azure is handling the swap.
Things to consider when deciding on your approach for carrying out a deployment to a Sitecore environment:
It does seem like a lot of to take in. But if you make a checklist and remember these key points your deployment experience should be less painful:
