In my pursuit of a blog platform (for personal use) that is easy to maintain and very portable I finally gave in and decided that running my own custom solution would be best. I already had a simple hobby website sitting in TFS and converting it into something useful would be the course of action.
I'll make a few assumptions here. You need to have a TFS online account (can be set up here: VisualStudio.com), Visual Studio and access to a Windows Azure website.
Have all those things? Great! Lets get started.
First things first, the TFS project where your website is stored needs to be linked to the Azure Website for automatic deployment. You can do this from the Windows Azure management portal by selecting your website and clicking on the 'Set up deployment from source control' button. A wizard will pop up to help you link TFS to your website.
This solution does not use a database to store the posts, instead it uses the file system. At the root of the site there is a folder called Blog which contains folders for images and posts. The posts are .md files containing Markdown syntax. I chose Markdown because of its simple format but still offering a very flexible way of writing content. Metadata about the post is stored in the file name.
Since the implementation can be done in a thousand different ways I won't include it here (maybe in another post) but to give you a few pointers:
- MarkdownSharp NuGet package to transform the .md files to HTML.
- Some custom code to extract the metadata from the file names.
- Some custom code to load posts from files.
- Controllers to load a homepage, archive, rss and single post.
The cool stuff is happening when I create a new .md file, write a blogpost and check that in. TFS will trigger a build process that was created by linking TFS to the Azure Website and auto deploy the website containing the new blog post.
The workflow to write a new post is now reduced to:
1. Create new file in /Blog/Posts folder with appropriate title.
2. Write post content in Markdown in new file.
3. Add any images to the /Blog/Images folder.
4. Check in.
And as soon as the build process is finished the site will be up to date with the new post.
Why not run a static site? Editing HTML is real pain if you ask me. I much rather write in Markdown and automate the HTML generation. If at any point I change my mind about my platform choices I can take my Markdown files and images and put them somewhere else.
As a bonus the deployed site has no login system and no database so it is a lot less vulnerable to exploits and whatnot. Always keep an eye out though ;-)
PS: Shameless plug - the stuff described above is running here: harrewijnen.net
