Upgrading the MuddlingThru.ca Blog to Orchard 1.9

Goals

Speed up the site and make it more readable.

• Use Orchard 1.9 instead of Orchard 1.8.
• Use Sql Azure instead of Sql Compact.
• Use a larger font, calmer background color, and simpler layout.
• Keep the existing simplicity and print layout.

Steps

First, export content from the existing site, using the Import/Export module. We did this in segments.

E.g. First, export the Blog.

• Blog
• Blog Archive
• Blog Post

On each export, we also included:

• Metadata
• Data
• Only Published Versions
• Site settings
• Roles

Then...

• Create a staging deployment slot in MS Azure.
• Create a staging Git branch.
• Connect the staging deployment slot to the staging Git branch.
• Download the Orchard Source (31 MB) into local Git staging branch.
• Create a custom deploy.cmd script for Orchard.proj that targets Precompiled .
• Add, commit,  and push the staging Git branch.
  • Force add the media/Media source files (because our global .gitignore ignores Media directories.)
  • git add **/src/**/[Mm]edia/* -f
• After Git Deploy has finished ( about 30-minutes the first time ), navigate to domain-staging.azurewebsites.net , which will show the Orchard Setup page.
• Create a new SQL Azure database.
• Link the database to the Web App.
• Continue thru Orchard Setup
  • Use the new SQL Server database.
  • Choose the Blog recipe.
• When setup completes, go to the Dashboard > Modules > Import/Export > Enable.
• Once enabled, import each export.xml file that we created in the first step.
  • We did the imports with the Orchard command line interface.
  • It's also possible from the web user interface, though we needed to increase the executionTimeout in the web.config.
• Our import took about 5-minutes .
• Finally, copy across the Media directory from master to staging .

Nice-to-Haves

• Replace the /lib directory with a Nuget packages.config file. Alternatively, can we just delete the /lib directory and have Nuget work anyway? I.e. read the *.sln file?
• Speed up the deployment.
  • Remove modules we aren't using, so the Azure Web App doesn't need to build them.
  • Create multiple deploy.cmd scripts, for different scenarios (e.g. just deploy static files with no build.)