Eventually time caught up with me, and with the help of some isolation, boring weather and some recent announcements from Microsoft Build, I had to go and update my/this web site. It was way overdue and it’s been on my to-do list for far to long - for a number of reasons. First of all this site has been hosted on Orchard on Azure since 2012 - without any hiccups. The setup was a dynamic web site, using Orchard, which was a state-of-the-art web and blogging CMS at that point in time. I loved the architecture and how they built it on .NET! However this setup required me to do upgrades once in a while, and eventually I stopped doing that due to some big changes, that I did not have time to mess with. So I let it be. Secondly this was running on Azure Web Site and using Azure SQL Server for backend - although fairly cheap, not optimal for my blogging cadence and the content. The interwebs has moved on and there are also more or less requirements to have your site on HTTPS, which I did not have previously. And last but not least I suck at design so I cringed to do an update.
I’ve been working on the move for quite some time, building an export mechanism that could export all important articles and pages from the Azure SQL Server, as well as all images and files. And Iv’e been fiddling back and forth with some static site generators, where Hugo was the one that pleased me the most. And last week during Build when watching the announcement on Azure Static Web Apps - Swah’s - I said to myself - “Let’s do it”.
My adventures with the SWAh
I quickly started with creating the SWAh, which was a super-easy thing to do, got it hooked up to a Github repo and published what I had. That did not work! When creating a SWAh, you are provided with a Github workflow that you would assume just worked. It did not. I bought in to that if you used one of the supported static site generators, such as Hugo, you were set to go. But I actually had to read the documentation for Hugo deployments. It turns out that you need to add some custom steps into your workflow - first install Hugo, and then build your site. Makes sense, right. But when you then look at the build output from the workflow, you will see that your site is built twice; once using the version of Hugo you specify, then by the one Micorosft provides (which is an old one, and not the extended version). If you run into this - follow this Github issue on the topic.
Then I started to fill my site with all the migrated content, images and files. And Boom! again!. Turns out that the SWAs has a maximum size of 100MB. Workaround for this was to spin up an Azure BLOB storage and set up my own CDN for all those assets. I kept all of it in the same Github repo, and modified the workflow to publish the blobs and then the site. That all worked out fine.
Then, yes I admit it, I had some serious issues with Hugo - new language and all, but that’s fine. I spent many, many hours on fixing an issue where the automatically list generated pages wrote over my start page. The logging for those events was/is sub par in Hugo, all I could see was that the same page was generated twice. I’m not going to go into details on what exactly caused this, but it was a config error on my end - but I will report that issue once I have made a small repo of it.
Next, was to create a good content publishing environment for me. Since this is a static web site and you need to republish to publish and scheduled posts and I wanted an environment where I could preview everything without taking the site down. Well, for this scenario SWAhs are not a good match. Yes, you get a preview environment, but that environment is created when you do a PR to your master branch with a random name etc. I wanted to have a real preview site I can use all the time. Unfortunately this is not supported (yet) with SWAh’s.
So, with all this in hand - despite some of the really neat features in SWAhs such as Azure Functions integration, Authetication support etc - I abandoned this journey. I just want to publish a static web site!
Back to my original plan - Azure Static Sites
My original plan was to use the real Azure Static Sites, hosted in the blob storage. Since everything was already setup with my workflow - publishing binaries to a blob storage, building the site (using those two extra Github Actions) all I had to do was to copy and paste my action for the CDN and point that to another blob storage resource. This took me just a few minutes - and I set up two of them, one for preview and one for the live site. I modified the workflow so that I have one Github Workflow doing all the job and depending on the branch it publishes to the different locations. One of the absolutley best experiences in this is how fast and easy it is to enable HTTPS for your site - a couple of clicks in the Azure portal and a few CNAME entries in my DNS and I have all setup with HTTPS and with certificates for my domain. I also added some rules to the CDN to always redirect to HTTPS - which should make all the SEO folks happy.
Since this is a static site, I also migrated all the comments from the old blog to Disqus. Man, that was an old school experience - XML files and a UI that looks like something from a way back machine.
That’s it
And now we’re here. It’s all up and running - it is faster, safer and most likely way cheaper. I’m pretty sure there are quite a few issues with the site, specifically the migrated content - that already been migrated once, from my home grown blog engine that I built 16 years ago or so. If you find anything, please chime in!
What’s next
Hopefully this gives me inspiration to write some more. I do have a few in mind already, specifically one about a custom Github Action that I created during this process - more on this shortly. And I also have some plans on writing some articles on a completley different topic than I normally have done here - don’t worry, it will be geeky!