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.
1. Aim for automation
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:
- TeamCity
- Octopus Deploy
- a combination of TDS/Sitecore Ship for managing our items within the Sitecore deployment 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.
2. Don’t forget your Sitecore items
Sitecore items can be a headache when it comes to deployments and there are many questions to consider, including:
- What’s been added?
- What’s changed?
- How do the changes affect any content?
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:
- Templates
- Components (renderings, layouts, placeholders)
- Site configuration
3. Configuration management
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.
4. The recovery position – plan for it
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
- How do I roll back the code?
- How do I remove the newly installed/updated Sitecore items that have been deployed?
- How do I revert the configuration changes that have been made?
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:
- Backup your databases
- Backup your applications Webroot (this will contain code and configuration_
5. “Downtime is not an option!”
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.
Deployment slots
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:
- Are you running one or multiple Sitecore CM instances?
- Once you make changes within Sitecore and publish them to satisfy the new code being released, will the old site continue to work or will it throw errors? (If running one CM instance with multiple CD instances)
- If it is likely to throw errors then you should consider the extent of these.
- Work with the customer to decide on whether a parallel instance is going to be a better choice
- Enable a caching layer (CDN) whilst the deployment is being carried out. This will ensure that any errors will not be visible to the end user. Once the deployment has been completed, the CDN can be refreshed or removed.
Summary
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:
- Aim for automation, choose the right tools for your business
- Don’t forget your Sitecore items
- Configuration management (in a scaled environment)
- The recovery position – plan for it
- “Downtime is not an option!”
.webp)