Improve your Sitecore deployment and streamline your processes with continuous deployment
By: Sitecore MVP Jason St-Cyr
The idea of continuous deployment of your Sitecore website may seem daunting, but we’re here to tell you that not only can you do it, it will improve your deployment and streamline your processes.
My favourite topic these days is trying to get folks to move over to a continuous deployment model where each code check-in goes straight to production. Mike Brittain, from Etsy, got me hooked back when I attended the 2013 ALM Summit and he did his presentation on “The Dirty Details” of continuous deployment.
Essentially, he broke my brain by explaining that they didn’t have a test environment.
WHAAAAT?
Yes. They deploy straight to production, multiple times per day and many multiples of times. The risk-aversion side of my brain was freaking out. How can you do this? What about the bugs?
Guess what? If you can fix a bug in 15 minutes and have it back in production 15 minutes after that, it doesn’t really matter. You’ve got 30 minutes between the time somebody notices an issue to when it’s resolved. Imagine your current process to get a fix to production, does it even come close?
There’s no way that would work for me
Let me be frank: you’re probably wrong. Unless you are running a website where somebody will have serious financial, legal, or health consequences from a bug, you are not running critical software. The site may be critical to your business, but your uptime requirements are probably in the realm of allowing an hour or so of downtime each month, therefore you can likely afford a bug here and there.
What you probably can’t afford is to spend a large portion of your marketing or IT budget and not get anything for it.
Continuous deployment solves that problem by putting what you are paying for directly into your revenue stream. Realistically, you will probably still hide a lot of it until the work is finished, or a package of features are available together, but at that point the power is in your hands to make it available to your users.
If it’s not tested, it’s not done.
I agree, completely. In fact, I usually enforce that a review of any user story work be a part of the definition of done. Automated testing is your friend here, and you can invest in it on an ongoing basis to build up the amount of checks you do before code lands on the production server. Unit testing will build your base, then build on that with automated UI flows, integration tests, and regression tests. By the time all these tests run, there’s very little that hasn’t been checked.
To be safe, you can hide stuff in production so that only testers can see it until you are sure.
How will I know if something is wrong?
This is where things start getting difficult. With this model, it’s inevitable that something will slip through, and because it is in production you’ll need to resolve immediately; monitoring becomes incredibly important. We need to be able to have monitors telling us if layouts are broken, if Sitecore is throwing unexpected errors, if indexes are not rebuilding, or if the job queue is getting backed up.
There may also be transactional portions of the site that we need to monitor to ensure that traffic and activity has not drastically dropped off due to some unknown issue in the business logic.
Planning for these monitors is really important, and needs to be done before getting rid of all our staging environments.
What about database changes?
Yup, you are right. This one sucks. At this point, we have no more testing environments, and the developers are changing templates, adding fields, adding new sublayouts, and all kinds of things to the database. We can use tools to directly deploy these changes to production, but how will this affect the production content of the site?
There is no easy solution here. For each case, there is a different approach. I’ve recently blogged about how you can handle templates and sublayouts for continuous deployment, but even there you have no full-proof solution. At some point, we have to accept that something might just break.
And then we’ll fix it.
This sounds risky
How many times has a deployment gone incorrectly? How many times have you found out somebody “missed” something pushing from one environment to another one? Mistakes happen. However, when those mistakes happen you usually are pushing 3–6 months of work at once, and losing the benefit of all of it when you have to roll back or fix it on the fly.
If you are deploying one single change directly to production, you are getting feedback faster from all of your testers, including your users. If it all goes well, you are also gaining the benefits of the change immediately. If we start building our software more incrementally, and doing it faster and better, doesn’t everybody benefit?
Also, don’t underestimate the power of removing the test environment from the equation to suddenly make developers check their code a little bit more before checking it in :)
Some other reads to help you tackle the beast:
- Continuous Delivery with Sitecore, Ben Scoll & Richard Johnston (Slideshare)
- Continuous Integration & Deployment With Sitecore, Jason Bert
- Sitecore Continuous Deployment: From Zero to Hero, Alexander Doroshenko
- Automating Sitecore Deployments with TeamCity and TDS, Jason St-Cyr
- Continuous Integration & Deployment with Sitecore, Jason Bert, (SVUG video)
