BlogDevOps

As I was mentioning the inaugural blog post, I was looking to build a simple but elegant solution to manage my blog, and as I went for the static site generator route, I was left with no “administration” panel to write and publish posts.

While researching my options, I noticed a lot of people were using GitHub to host their sources, and deploying either to GitHub pages or to other hosts via Git hooks. But I wanted to use the infrastructure I already had in place using Visual Studio Team Services to host the code and Azure Websites for hosting.

The process - how does a static site work?

First of all, I had to understand how Hexo works (and pretty much any static site generator for that matter). This wasn’t very hard, you just need to read the readme file of the tool. I’ll lay it out in a few words. First you need to install the tool, usually using npm. Once you have it, you can initialize your blog in a new folder - I’m not going to go into any more details about this, maybe another post. Suffice to say, this folder is now your “source” for the blog. Since the tool has quite a few dependencies, you need to run npm install to ensure they all get deployed in your folder as well. Once you have that, you run a command to generate your site - same as you would compile your sources in any other language. The result of this compilation is a folder that is essentially your entire site - a self-contained website consisting of just a bunch of HTML, CSS, JS and images. The idea is, you take this folders and publish it anywhere and you’re done with it.

The goal

So my goal for the blog deployment was to be able to host my code in Visual Studio Team Sarvices in a Git repository and every time I write something, commit the article and via some magic in the next couple of minutes my Azure Website would show the post. I could commit a new markdown file in the repository from anywhere or any device and it I would get a new post on my blog. No need to worry about compilation, deployment, or anything

The journey

Like everything else, I expected this would be a process so I started looking at my options, always having my goal in mind and knowing that I might not get 100% there the first time.

1. Manual mode
   First and easiest option. Install Hexo on my local machine, generate the site locally, then upload the public folder to azure via ftp.

   Of course, this is absolutely nowhere near my goal. There’s no automation whatsoever and every time I need to write a post I have to perform a number of manual steps and worst of all I either have to do it from my computer, or in any case, a computer with all the tools installed.

2. Semi-automatic
   I could easily automate deployment using Visual Studio Team Services build or release management. I can create a build process in VSTS to publish the public folder to azure websites every time I commit.

   The problem with this approach is that I still have to generate the site locally, which means I need the tools installed, and it’s against the best practices to include the public folder in Git.
   So we’re still a bit off our goals but we’re on the right track.

3. Fully automated - with VSTS
   Seeing that I can automate with Visual Studio Team Services build system, I went ahead and pushed everything in the build process.
   
   So let’s look into what is going on.
   Since I am using the free tier of Visual Studio Team Services, I am using the default build agent (you get 240 minutes of build time every month, but that means I don’t control the agent itself which means I have to make sure I have everything I need to build the site every time I build. So in the first 2 steps I make sure I install Hexo and the dependencies. I then package the public folder in a zip (using an excellent 3rd party plugin for Visual Studio Team Services). Once that’s done, I deploy the zip to Azure.

   I was happy to say that I’ve achieved the goal with this one but then I realized that there’s a big inefficiency in the process - specifically at step 2. because I don’t control the agent, I must install all the dependencies every commit. This takes around 100s, so every time I commit, I am using 2-3 minutes of build time, most of it just downloading packages. I contemplated, putting them in my Git repo, but I was hoping there’s a better way.

4. Fully automated - with Azure
   So, having my automation going, I was now in bonus points mode. I was reading that there are ways to have my Azure Website register a Git hook and pull the code every commit and deploy it. There’s even an Azure WebSite extension that fully automates a Jekyll deployment but I couldn’t find anything for Hexo.

   Then I found Tommy’s post that gave me hope. I used his instructions to get it started but it didn’t work - I was committing, but my blog would not get deployed. So after some more digging I found the solution (my apologies, I can’t remember the original link). To get Azure to trigger your deployment you need a file called “.deployment” in your root folder that simply calls the deploy.sh script:

   [config]
   command = bash deploy.sh

   The biggest advantage over building the site in Visual Studio Team Services is that the node packages are actually cached so they are not downloaded every commit, making the deploy a lot faster. Also with the Git hook, the Azure Website is getting the code from Git directly so I don’t have to worry about deployment anymore.

Finally I was happy with the deployment process. I think it’s easy, efficient and elegant and it definitely meets all the requirements I set at the beginning.

Update:
One of the reasons I wanted this full automation, was so that I can contribute to the blog from any device at any time by just committing some markdown file to my repository. Problem is, being the markdown noob that I am, I still learning the ropes on formatting, links and images so I need to generate the site locally to make sure it looks legit before I commit (I found some online markdown editors but I found that there are some differences between them and what Hexo generates) Hopefully in time, I will get better at it and I can do it blind and then my investment now will pay off.