Recently, I had a chance to run a ‘pilot’ project for a customer to demonstrate to them the capabilities of automating their Sitecore deployment with Sitecore Azure 7.2. Sitecore Azure is a Sitecore module developed to ease deployment of your Sitecore Solution to the Azure Cloud Service, typically known as Platform-as-a-Service (PaaS). This article will attempt to show you basic ideas on how to get started with configuring your setup to support the Sitecore Azure module for ease and automated deployment of your Sitecore solution to the Cloud. I will demonstrate this with a typical deployment scenario of a Staging delivery farm and thereafter later, how this can be promoted to become a Production delivery farm.
With some valuable experiences learnt along the way, I hope this article will be able to benefit other readers so that they do not face the hard and bumpy challenges along the way. However, if you think that there you may have an opinion to share, you are most welcome to comment on this article.
One note is that circumstances may vary to your situation and requirements. It is recommended to verify which Sitecore Azure module is compatible and suitable to your requirements. For the Sitecore Azure compatibility matrix, refer to the official table. Once you have decided on the correct module version, install the Sitecore Azure module onto the CM using the UpdateInstallationWizard page.
I will not explain the detailed installation steps of the module as this information is ready made available in the SDN documentation of Get Started with Sitecore Azure.
Installing the Management Certificate
Communications between Azure and Sitecore Azure requires a secured channel to transmit data from Sitecore Azure to the Cloud Service. You will first need to setup a management certificate for Sitecore Azure to be given authorization to send requests to Azure via the Azure Rest API Management Service.
I proceeded with option A) of downloading the .publishsettings file from my current Azure subscription (https://manage.windowsazure.com/publishsettings/index) and then uploading this management certificate (this certificate holds both the private and public certificate to Azure) via the Sitecore Azure prompts. Note you will be prompted to upload a management certificate after the first time you have uploaded your Sitecore Environment File. This Environment file is unique to your Sitecore solution is usually obtained from Sitecore within one or two days after a request has been made.
Once this is done, Sitecore Azure will be able to submit API service request calls to Azure to manage your Sitecore deployments.
One note is Sitecore addressed two bugs around this upload management certificate. It will be important to apply the below kb fixes.
- Error installing a management certificate for Sitecore Azure without the appropriate application pool permissions (https://kb.sitecore.net/articles/823113)
- Error installing a management certificate in Sitecore Azure when using the 2.0 format of the publish settings file (https://kb.sitecore.net/articles/075335)
As an optional setup, you can also manually configure SSL in Sitecore Azure using this KB article (https://kb.sitecore.net/articles/661557)
Creating a Staging Delivery Farm
I then create a delivery farm that will host my CD servers in PaaS in the staging slot. Notice that the environment type is set as ‘Evaluation [Staging]’. CD servers in PaaS are typically called ‘Web Roles’. In my case, I created five delivery farms (three that are Production and two that are Staging).
Sitecore Azure provides a integrated user interface to visualise the various deployment spots across the globe. I will recommend choosing a data centre closest to your area to minimise cost.
The deployment topology used in my use case is the “Delivery” Deployment topology meaning that only my CD servers are hosted in PaaS and my CM remains hosted on-premise. See figure above with only Delivery farms listed.
When you first add a delivery farm in a given datacenter region, Sitecore Azure brings up the New Deployment dialog. Choose the Number of instances and VM size appropriate for your environment. I choose to use the Default settings since this is environment is a staging environment and used only for evaluation purposes. By default, Sitecore Azure sets the number of instances to 2 and VM size to Small.
For production purpose, Microsoft recommends at least a minimum of 2 instances to satisfy the SLA agreement of 99.95 percent high availability.
After you add a delivery farm, Sitecore Azure creates the Delivery Farm item in the Sitecore Content Tree. For example, after I add DeliveryFarm05, Sitecore creates DeliveryFarm05 as a Farm item with its necessary child items at /sitecore/system/Modules/Azure/[Environment-Name]/[Region Name
Do not click Start Deployment yet. Click on the more options which brings you the Staging Deployment content item created. In this example, it navigates to /sitecore/system/Modules/Azure/SomeProject-Evaluation/Southeast Asia/Delivery05/Role01/Staging. You will see an example like the figure below.
By default, the Delivery Farms will be set to share the same Production and Staging databases. Leave this as-is.
Database references are set to point to existing databases. This is my preference. I do not wish for Sitecore Azure to create the Sitecore databases for me as this will consume extra time for deployment. Instead, I configure it to point to the existing sitecore databases (core, master, web, analytics and wffm).
Ensure that the Connection Strings Patch field is also set correctly with the same database connection strings as specified in your Database Set (set01). See figure below. Refer to this KB article for more information. (https://kb.sitecore.net/articles/440060)
Next step is to ensure that your service configuration and service definition fields have been configured correctly. Ensure that the following fields are set correctly particularly StorageName, Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString and Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString. Ensure SqlServerName is left blank. These will create the Sitecore Logs in Azure as tables upon deployment of the Delivery Farm. For more info on how Sitecore Azure creates IIS logs, WADLogs, etc, refer to this KB article (https://kb.sitecore.net/articles/400950)
Once completed with the above, you are ready to Start Deployment. You will expect Sitecore Azure to create a brand new staging slot for DeliveryFarm05 if this has not been created yet. Whilst deploying, Sitecore Azure will perform the following in order:
1. Resolve databases
2. Builds the package
3. Applies the service configuration changes.
4. Executes the package
5. Creates the package
6. Uploads the package to Azure
7. Deploys the package to Azure
8. Runs any start up tasks specified in the service definition file if any.
9. Finally it runs the deployment and starts up the Web Roles.
The deployment time will vary depending on factors such as the size of the solution deployed and network bandwidth.
Sitecore Azure dialog displays the status messages indicating the progress of the deployment all the way up when all Web Roles have finished starting up to 100.00 %.
Once deployment is done, you will be able to see the green globe of Delivery05 in the Sitecore Azure dialog as below. This means the Delivery Farm has started successfully and is running.
Turning over to your Azure Management Portal whereby Sitecore Azure is linked to your account subscription via the Management Certificate Trust, you will be able to view the Staging Deployment Slot. For example, Delivery05 delivery slot is created as below.
Microsoft Azure permits up to a 100 farms per region. In real life, you will not be deploying as many as that into a production setting. So please be prudent about this choice. Note the more farms you have, the higher costs incurred upon you by Microsoft.
Promoting a Staging Delivery Farm to a Production Delivery Farm
Once staging is up and running and after the evaluation process is decided, you can easily promote the staging delivery farm to be a production delivery farm. Sitecore Azure offers the Swap in to swap a staging and production deployment by swapping the virtual ip addresses both deployments. This is known as VIP-SWAP. VIP-SWAP incurs no downtime cost and is extremely fast. When a VIP-SWAP is performed, production deployment be swapped in with the previous VIP of staging and hence the staging deployment slot becomes empty and the production deployment slot is replaced by the staging deployment content. This can be seen in Azure Management Portal once the VIP SWAP is done. This blog explains it well (http://blog.toddysm.com/2010/06/update-upgrade-and-vip-swap-for-windows-azure-servicewhat-are-the-differences.html)
To perform the VIP-SWAP in Sitecore Azure, you will click on the swap command entry. Note: This is essentially the same Swap command available in the Azure Management Portal. Sitecore Azure has provided a nice shortcut for Sitecore admins to perform this action in the dialog popup.
Once done, you will be able to see that the Production Deployment slot is now filled in with what was seen in Staging before. Swapping will typically take a short moment to complete making promotion so much faster and easier. When the swap completes, you have successfully promoted your site to Production!
Typically the below will be the status flow:
See figure below.
Production Deployment Slot:
Staging Deployment Slot:
Hope this helps those who are encountering with Sitecore Azure for the first time. Feel free
to drop me questions or share opinions if any.
Overall, I found the experience with Sitecore Azure very seamless and it automated alot of the tedious deployment work required for a Sitecore Instance solution be it for small to large scale. It does introduce a very streamlined approach when it comes to deploying code based files and configurations to Azure Cloud. Although there are other mechanisms of deploying a Sitecore solution manually to Azure PaaS, Sitecore Azure does provide a nice visual of the statuses of your deployments in each delivery farm you deploy to.
That said, there are further tasks required to be investigated such as, startup task capabilities such as automating 3rd party antivirus installation, instrumenting application performance monitoring on the web roles etc. Will yet to see how Microsoft is able to provide some useful managed services around these areas for recommendations to our customers moving forward with the advent of Azure Cloud Services.
For some useful references to Sitecore Azure, refer to the below which proved very helpful in my personal findings.
Sitecore Help 
Hello,
We are using claytablet with sitecore 7.2 and facing a lot of performance issues. Did you face any problems while working with claytablet and sitecore
Noob question .. When creating a swap slot in Azure portal Do we need to create seperate storagge accounts for Production and staging slot ?
Hi Weeder, I suppose there is no harm to use the same storage account as ultimately both primary and secondary slots are sitting within the same resource group location. You might want to consider deploying your site in delivery farms which is distributed in two or more locations more for disaster recovery purpose.