If I have to do a deployment, I don’t know about you but I’d rather deploy at 11 A.M. than 11 P.M. I guess I value my sleep. I also really hate putting up a maintenance page like the Apple Store likes to do anytime it does a major inventory change, usually during a new product launch. Using my strategy below, I was able to deploy a new language without bringing down our existing sites and without telling our users to “come back later.” Here is how to do to it.
If you have made any modifications to your Sitecore templates, chances are those modifications affected both languages. Therefore, simply clicking “Publish Site” and copying the binaries and other files won’t really work. It will, but deploying an enterprise-sized site blindly without a smoke-test for a public company and not running into any issues is about as probable as winning the lottery. If you do not agree, see the definition of Murphy’s Law here.
Server Setup
This is the setup that is recommended by the engineers at Sitecore. There are three identical web servers that are the delivery servers. There are also four databases - Core, Master, Web (staging preview), and LIVE which is the main production database server.
You will want a complete backup of the LIVE database as the initial step. Don’t even open the web interface until you do that.
Web Server Preparation
If you have a load-balanced web server environment, you will want to take one server out of the load balancer pool. This will be your smoke test box. If you are deploying on a different domain (read my previous post on that strategy if you are unsure), you will need to modify your hosts file, usually located in c:\windows\system32\drivers\etc directory, to direct traffic to your site. There is actually a benefit to doing this – testing out your SSL certificate to make sure you don’t get any certificate warnings.
If you do not have a load-balanced environment, you can simply clone the web directory and create an additional IIS site pointed there.
Database Preparation
By now, you should have already a complete backup of your live production data. Note the path down somewhere and hopefully you won’t need to use it. Next, create an additional complete backup of your database and restore it as a new database with a different name (e.g. Sitecore_LIVE_Temp). This will be your temporary stand-by database that your live website will be running on, while you smoke-test your environment.
After you have verified that the database restored successfully, you can now go into your ConnectionStrings.config file and switch over the database in the “web” value to this new one you have just created.
Publishing
Now that you have set yourself up with a copy of the live site and the main database, which is going to be your live database after the testing concludes, you can go refill that cup of coffee, take a breather, and slowly begin the publishing process. You could press “Publish Site,” but I prefer to publish section by section, just in case someone activated an unpublished item that should have stayed unpublished – “Trust, but verify,” as Lenin used to say. I do templates, layouts, media library, and then content, followed by copying over any binaries and other files to the web server. In the web preparation section, you should have also already created a DNS record in the hosts file for your site – one for the main site, and if deploying to multiple domains, one for the new language.
Smoke-Test
By now, you have published all the languages, copied over the binaries and files which are now running on the LIVE database, and your hosts file has been modified. At this point, start your testing. Concentrate on user registration, if you have this component, which probably talks to a different, non-Sitecore database. It also uses an SSL encryption, which lets you test your certificate situation. Assuming you did your heavy-duty system, integration, and regression testing on your staging environment before you started this process, do a general walkthrough of the site, making sure all the content loads correctly.
Make The Switch
If all was good in the smoke-test, congratulations! You are pretty much in front of the finish line. The final step is to copy the entire site you have been testing to your live web environment. If you are deploying to a different domain, the other additional step will be to turn on the site in IIS, if applicable.
Since that site already has the correct database in its ConnectionStrings.config, your current production sites will automatically redirect traffic to them, as soon as they restart. You can do a quick iisreset just in case, but the new overwritten assemblies in your bin folder should probably kick off an application restart.
