Earlier this year, in March of 2013 ( all posts on the topic ), I relaunched my site using the open source CMS engine Orchard CMS . I based my deployment on the 1.6 release which was the most current stable release at the time. I’ve been very pleased with the engine and have enjoyed doing some customizations to the codebase as well not to mention some minor contributions to the project in the documentation and bug fix areas.
The deployment of Orchard on this site was fairly uncustomized. I only made three changes to my site that included the following things:
- Added five (5) third party modules from the Orchard Gallery which included:
- Contrib.Cache – used for performance caching, specifically output cache and database caching
- Contrib.RewriteRules - I used this to implement HTTP 301 and 302 redirects as my URL addressing scheme changed from the previous engine I was using and I didn’t want to lose any of my page ranks or notify others of the new URLs
- Orchard.Disqus – I outsourced all comments on my pages and blog posts to the Disqus engine and this module enabled me to easily add the necessary JavaScript to relevant pages.
- SH.GoogleAnalytics – this module easily added the Google Analytics tracker… frankly if you aren’t using Google Analytics, you have no data on who’s coming to your site and more importantly, how they got there
- Vandelay.Industrties – this module is a collection of various things like FeedBurner, favicon, metadata, tag cloud etc.
- Created a custom theme for a personalized look and feel
- Source code tweak so Orchard wouldn’t look at a local /Media folder for all content images I use in my site, rather I wanted it to look at a Azure storage blob account. To do this, I followed the changes outlined in this thread on CodePlex
At the time I then just compiled the project and deployed the codebase to my Azure website via FTP. This was pretty easy as Orchard includes a few build scripts to compile everything and run the automated tests.
However I quickly realized, a few months down the road, this was a shortsighted plan. Why? Because when the Orchard guys had a new release (like a patch to 1.6.1, or a major update to 1.7), I would have to re-implement all my changes. I was keeping everything in source control using Team Foundation Service, but I was maintaining my own copy of the codebase. That meant I would have a significant amount of work to update my codebase to match what all the other developers on the Orchard project were doing. I needed to figure something out. This was not just going to affect my site, but a few other sites I maintain as well as those for a few customers who I’ve migrated from one CMS solution over to Orchard in the last year.
Earlier this summer the Orchard team switched their source control from Mercurial over to Git. I had been interested in learning and using Git, but I hadn’t taken the time. Through a few community events and some research online, I realized this could be a great solution to what I was trying to do. Admittedly Git isn’t the silver bullet to my issue and I could have still addressed it with Mercurial or TFS, but Git was well suited to this. In addition, I noticed the folks at Azure added support for automated deployments to your Azure web sites using Git. Oh yeah… now we’re on the right track.
I knew what I wanted: I wanted to easily get the most recent changes from the master Orchard source tree. I then wanted to easily make edits and changes to that tree but keep them separate but I also wanted to easily make contributions to the Orchard project and submit changes as a Git pull request. Further, when there were updates to the Orchard source, I wanted to (on my schedule) merge those changes into my custom implementations so my local implementations were always on the most current release, but I didn’t want the process to be tedious or have any repetitive work such as having to re-apply my code changes. Finally, I wanted to be able to have this handle multiple Orchard deployments without having to duplicate the work across all of them.
Over the last few days I took some time to build a process and test it thoroughly (big thanks to Chris Johnson for answering a lot of Git questions… I’m still “getting Git”, certainly not at the “got Git” stage). Today I am very confident this process will work for me, but I’m sure there is room for improvement and optimization. However it’s pretty clean and streamlined as is.
In the next post I’ll dive into the details of how I set up the process, remote & local repositories & clean deployments to Azure Web Sites.