Blog

Azure Sitecore Deployment: Adding Project's Code and Items to the Azure Deployment

August 03, 2017 | Charlie Turano

This is part 4 in the series of blog posts on Sitecore deployments on Azure. The other posts in this series can be found here:

Part 1: Setting up the Solution and VSO Build
Part 2: Preparing the Default Scripts and Packages for Azure Deployment
Part 3: Adding Custom Modules to an Azure Deployment

In the previous post, we setup a complete Sitecore Azure instance, adding some custom modules to the default install.

Now we want to modify the scripts so that the compiled LaunchSitecore site is also provisioned into the new XP environment that setup. To make this easy, we decided to use the MSDeploy package created during the VSO build (see part 1 in this series). This package contains all the compiled code for the site. The compiled code for the CM and CD should be exactly the same.

Cleanup Prior Post's Resource Group

First, make sure you remove the resource group you created in the previous blog post from your Azure account. We are completely recreating that entire resource group....but, as mentioned, we're adding our project's code into the mix (through the MSDeploy package our build created). This way our default install will be Default Sitecore + the Sitecore Package Deployer Module + the MSDeploy package from our project.

Setting up the install script to push an MSDeploy package generated by a build server is relatively simple.

Upload the custom scripts to allow for MSDeploy packages to be installed.

The first step is to upload our custom scripts to the Sitecore container in blob storage that was created earlier (with the default scripts). Upload our custom scripts for MSDeploy. Place these in the same relative folder path (/xp/custom) so that the relative paths continue to match up.

Create Sitecore Folder in Blob Storage

Updating the deploy parameters

The deploy script needs to be configured to deploy the MSDeploy package into the new instance using the "modules" configuration section of the azuredeploy.parameters.json file. This is the same location that we added the custom module, the Sitecore Package Deployer, in the previous post.


"modules": {
  "value": {
    "items": [
      {
        "name": "bootloader",
        "templateLink": "https://????.blob.core.windows.net/sitecore/xp/addons/bootloader.json",
        "parameters": {
          "msDeployPackageUrl": "https://????.blob.core.windows.net/sitecore82u3/Sitecore.Cloud.Integration.Bootload.wdp.zip?[shared access signature]"
        }
      },
      {
        "name": "sitecore-package-deployer",
        "templateLink": "https://????.blob.core.windows.net/sitecore/SitecorePackageDeployer/SitecorePackageDeployer.azuredeploy.json",
        "parameters": {
          "msDeployPackageUrl": "https://????.blob.core.windows.net/sitecore/SitecorePackageDeployer/SitecorePackageDeployer-1.8.scwdp.zip"
        }
      },
      {
        "name": "launch-sitecore",
        "templateLink": "https://????.blob.core.windows.net/sitecore/custom/InstallMSDeployPackage.azuredeploy.json",
        "parameters": {
          "msDeployPackageUrl": "https://????.blob.core.windows.net/LaunchSitecore/Release1.2.zip?[shared access signature]"
        }
      }
    ]
  }
}

The first two modules should be the same as configured above. The last one is the new one, and it uses the InstallMSDeployPackage script from our GitHub and the MSDeploy package created during the build.

Simply upload the MSDeploy package to your blob storage, just like the other packages, and copy the URL (with Shared Access Signature) into the config. Also upload the InstallMSDeployPackage.azuredeploy.json file into your blob storage, and copy the URL into the config.

That's all it takes to get out custom code included in the default install. We can now run the Install.ps1 script to setup the entire instance, with the custom module and our project code included.

Deploying the Sitecore Items

Once the website is setup and running, the Sitecore items can be deployed to the new Sitecore instance using the Sitecore Update Package generated during the build and the Sitecore Package Deployer installed on the CM. Simply ftp the .scitem.update package created during the build to the [cm ftp address]/site/wwwroot/App_Data/SitecorePackageDeployer folder. The package deployer will find the update package and install the items in the Sitecore database.


Please Note: We experienced some performance problems deploying items on the CM server when the application logging was set to "Information". Your results may be different. Please see these options for improving the performance of the update package installation

When the item deployment completes, you should publish the site and have a complete working Sitecore instance in the cloud.

In the next post, we will be utilizing an Azure 'staging slot' to give us zero down time deployments

Catching up? Start at the beginning! Check out Part 1 of our series, or read the complete project on Github.

Azure Sitecore Development Deployment

Related Blog Posts

How Feydra Improves Front-End Development for Sitecore
Feydra offers a more efficient modern approach to front-end development workflow for Sitecore.
Guide to Sitecore Packaging
Development of features and components requires a set of Sitecore items to be packaged - things like renderings and templates. With TDS Classic, Sitecore developers can automate the packaging process. 
TDS Classic: Content File Sync
Content File Sync is a fantastic time saver for any Sitecore developer.
TDS Classic How-To: Perform Unattended Installation of TDS Classic for Visual Studio 2017
The TDS Classic version for Visual Studio 2017 is installed a bit differently than previous versions; the process is separated in two parts and performed by two different installers.
TDS Classic 5.7 - Lightning Deploy
Lightning Deploy Mode can be used to enable Lightning Mode for all deployments that utilize the TDS Sitecore Connector in their configuration, improving their speed and efficiency.
TDS Classic 5.7 - Lightning Sync
Lightning Sync allows both sync and quick push operations to use TDS Classic 5.7's new Lightning Mode feature
TDS Classic 5.7 - Solution Wide Sync
A simple new feature in TDS Classic 5.7, Solution Wide Sync makes a big difference when working with many TDS Classic projects in a solution.
TDS Classic 5.7 - Lightning Mode
Lightning Mode helps to improve the speed and efficiency of both deploy and sync operations. This enhancement is achieved by modifying how item comparisons are performed.
RAZL Best Practices: Lightning Mode and Deep Compare
From scheduling Razl scripts to sync changes between Production and QA environments to keeping logs from scheduled Razl scripts, our team has a few tips and tricks to make the Razl experience even better.
Azure Sitecore Deployment: Deploying to a Slot
Setting up Azure staging slots, so the next release of our project can be placed there, allows us to deploy the new code to a private website (the slot), and test it before pushing it live. We are going to script this process to make it easier for the devops team to automate.
TDS Classic Best Practices: NuGet Build Components and TDS Classic .user configs
There are certain systems and processes that you can put in place to make a TDS Classic project run more smoothly. We're highlighting the best practices that our team recommends for getting the most out of TDS Classic.
TDS Classic Best Practices: Bundle Packages, Delta Builds and Delta Packages
Following TDS Classic best practices, like using Delta Builds and Delta Packages, can make the entire development experience run much more smoothly.
Azure Sitecore Deployment: Adding Custom Modules
Modify the previous install so that the initial install contains the Sitecore Package Deployer module. It is an excellent way to enable continuous integration to the website.
TDS Classic Best Practices: Validators and the Sitecore Package Deployer
TDS Classic can be used in many ways, but the goal is always the same: make development (and developers lives) easier. Whether it's using the Sitecore Package Deployer or using validators, following best practices can make your entire experience run much more smoothly.
Azure Sitecore Deployment: Preparing the Default Scripts and Packages
Preparing the default packages for a Sitecore Azure deployment and extending to add a custom module to the install.<br> <br> <br> <br> <br>
Azure Sitecore Deployment: Setting Up the Solution and VSO Build
<p>The first in our series on setting up a Sitecore instance on Azure, with an initial deployment that includes custom built modules as add-ons to the setup.</p>
Troubleshoot and Prevent Failed TDS Classic Project Builds
When building an .update package with TDS Classic, the build might fail with no additional information. From increasing log verbosity to using validators, there are ways to minimize or prevent this type of error.
TDS Classic How-To: Disable Automatic Code Generation
Code Generation is automatically triggered after every change in the TDS Project tree. If a project contains many items, users can disable this feature for their convenience.
TDS Classic Sitecore Deploy Folder
Sitecore Deploy Folder is a setting, located in the build tab of the TDS Classic Project's Properties page, and used to tell TDS Classic where the webroot is located.<br>
TDS Classic Builds on Jenkins Build Server with NuGet Packages
Our simple scenario includes 2 developers using TDS Classic and checking-in changes to source control. The Jenkins build server takes the changes and performs the build, and then deploys the created package to two Sitecore environments.
Features to Improve Sitecore Development: TDS Classic Strikes Back
Each and every feature in TDS Classic is aimed at helping developers. Whether the feature is out front or running quietly in the background the goal is always the same: make the development experience better. &nbsp;&nbsp;
Feydra and the Virtual Sandbox
Feydra virtualizes all front end assets (css, js &amp; cshtml) of a Sitecore instance. With Feydra, front-end developers can commit their changes to Source Control without requiring the intervention of a back-end developer. We call it a virtual sandbox.&nbsp;
Feydra Frequently Asked Questions
Answering a number of excellent questions we've gotten from the community regarding Feydra, including how long it takes to set up a Feydra environment and how to install the product.&nbsp;
TDS Classic Features to Improve Sitecore Development
Each version of TDS Classic comes with the same goal: to make Sitecore development and, by extension, developers, lives easier. Every feature in our products is aimed at making the process better - some of these features aren't quite as well-known as others, but they all help smooth and improve the development experience.
Deployment Properties and the Deployment Property Manager
When working with TDS Classic, you will eventually need to deploy your items to a Sitecore instance and you might not want the default behavior of every item in your TDS project deploying every time. This is where the TDS Sitecore Deployment Property Manager comes in!
Feydra: A Front-End Assessment
Feydra allowed me to start building the front-end in a very short time with no Sitecore experience, and it let me use tools that I was comfortable and familiar with.
Feydra: A Quick Start Guide
A step-by-step guide for installing, configuring and, most importantly, using Feydra from the front-end.
TDS Classic 5.6 Feature Spotlight - Prevent Deployment of Incorrect Assemblies
This feature, new to TDS Classic 5.6, will prevent a solution from deploying unless all assemblies (except the excluded assemblies we allow you to specify) match what exists in your webroot.&nbsp;
Feydra from the Front-End
Feydra eliminates common roadblocks for designers and front-end developers working on Sitecore projects by getting them up and running more quickly and allowing them to use the development environment and workflow tools they prefer.&nbsp;
TDS How To: Install the TDS Connector for Rocks 2.0
Manually install the TDS connector for Sitecore Rocks 2.0
Create TDS Classic Custom Post Deploy Step
Team Development for Sitecore Classic version 5.5 allows developers to add post deployment steps to to their deployments and update packages. TDS Classic has used post deployment steps internally to perform a number of useful functions. Many of the developers using TDS Classic have requested the ability to add their own post deploy functionality. With the release of TDS Classic 5.5 in early 2016, this functionality is now available.
Using NuGet Packages in TDS
New to TDS 5.5 is the ability to create and consume NuGet packages in your TDS project, allowing developers to capture their Sitecore items and easily distribute them across multiple teams.
Occasional Issue Seen with TDS Installer
When upgrading to TDS 5.5.0.x from an older version and trying to load a solution with a TDS project inside, the following error might occur:
TDS: The Evolution of Auto-Sync
Auto-Sync has been described as a new feature, but in reality has existed in TDS since 2010 and has taken a new form in TDS 5.5, due to be released March 22, 2016
TDS for SC Hackathon 2016
For all those participating in the Sitecore Hackathon, check out our Habitat for TDS and some other cool surprises.
Config Transforms for Config Files
If you don't want to use a third party development tool for your config transforms, I have good news. Config transforms are supported natively within TDS!
Package Installer from the Command Line
The TDS package installer allows you to install packages through the command line. Learn how...<br>
New Build for TDS 5.0!
A couple bugs were reported over the last few months. We've been able to fix the bugs and now have a stable CTP version for use.
It's finally here!
Team Development for Sitecore has finally been released go download it now!
Team Development for Sitecore Webinar
Our Sitecore MVPs Charlie and Sean recently did a demo of TDS to all Sitecore partners. We recorded the demo to share with the world.