Before I finally settled with using Web Deploy for deploying my site to Azure, I was also considering using FTP directly from Grunt. I quickly chose grunt-ftp-push as the most promising package for this purpose. A greater challenge was finding a way to keep my FTP credentials out of my gruntfile and source control.
After successfully migrating the content from the old DasBlog site to the new DocPad based one, it was time to generate permanent redirects of old URLs to new ones. Since the site is going to be hosted in Azure, I decided to use the URL Rewrite module - rewrite maps to be exact; because I need to map a large number of individual URLs, which can't be covered by a generic rule.
One of the most daunting parts of replacing my current blogging platform DasBlog by a site created with DocPad, is the migration of existing content. Being a software developer, I wanted to automate as much of the process as possible. Even if the total time required wouldn't be all that much shorter, I'd rather spend it writing scripts and learning new tools and technologies, than doing mundane tasks.
Since WebStorm is my JavaScript IDE of choice, I also wanted to be able to debug my Grunt scripts directly inside it. WebStorm has built-in support for debugging all kinds of Node.js scripts, including Gruntfiles written in JavaScript or CoffeeScript. It just needs to be configured correctly.
Writing a build script was only the first step in setting up continuous integration. In this follow-up post I describe how to configure TeamCity for Grunt and provide a couple of hints how to make it work even better.
Since my first DocPad project is slowly nearing completion, it was time to create a build script for it. I decided to use Grunt, which allowed me to achieve everything I wanted to: generate the static site, detect broken links in it, and deploy it to the web server.