Feeding The Machine · DevOps

Switching From Hugo to Astro

Mon, 31 Aug 2026 18:00:00 GMT

This site used to run on Hugo. As of last week it runs on Astro, and the switch took an evening. Two things about that are worth writing down: why I left, and how the leaving went, because the second one is the part I did not expect.

The honest version of why I left is that I never got comfortable with Hugo. I used it for a couple of years, it worked, it was fast, it never lost a post, and every time I opened the repo it was with a small feeling of dread about what I was going to have to look up to get a post out.

The clearest evidence sat in my own content folder. There was a draft post called “Hugo / Obsidian Blog Workflow”, dated February 2025. Title, date, tags, draft: true, and then nothing. Eighteen months of not writing the post about how comfortable I was with my setup. The workflow I was trying to build just never came together, and nothing else managed to take its place. That is a review in itself, if you are willing to read it as one.

The specifics are unremarkable, which is the point. The site was a third-party theme pulled in as a git submodule, which makes customizing it a negotiation with someone else’s markup. The config was a 152-line YAML file, of which 84 lines were keys with no value on them: blank settings for a theme’s features, sitting in my repo, doing nothing except being things I might be supposed to understand.

My favorite artifact of that file is that comments were turned off, and it still enumerated eight different comment providers. Disqus, DisqusJS, Utterances, Remark42, Waline, Twikoo, Giscus, Gitalk. Eight blank configuration blocks, in version control, for a feature I had disabled. None of which is really Hugo’s fault; it is aimed at people who want that surface area. It is just more machine than I need, and I never built the fluency that would have made it worth it.

The second half is the part I actually want to tell you about, which is that I didn’t really do the migration. Claude did, and what could easily have eaten a month of weekends landed as one commit on a Sunday evening. 191 files, about ten thousand lines added, six hundred deleted. Twelve posts (well, eleven posts and one shameful draft) and three pages carried across, the theme submodule gone, the 152-line config replaced by a src/lib/ directory where the logic is code I can read.

At this point, with AI’s help, speed is a given. The part that surprised me is which work got done because of the speed.

Think about migrating a blog by hand. You know the real risk is URLs: search engines and other people’s links point at the old paths, and Hugo was emitting paginated lists, per-tag pages, per-tag feeds and legacy aliases from an even older version of the site. You also know that cataloguing every one of those before you delete them is an hour of tedium standing between you and the fun part. Reader, on a Sunday evening you are not doing that. You are going to eyeball the homepage, click three links, and ship it.

What happened instead is that Claude audited 73 old URLs that went into a fixture file first, and that became a test that fails if any one stops resolving. Then a crawler that fails on any internal link, image or anchor that does not resolve. Then invariants on the content itself: every tag has a glyph, every post has a hand-written excerpt, no unconverted Hugo shortcodes anywhere. The suite is up to 331 tests, and it runs before every deploy.

That is the leverage that Claude brought. Not the speed directly, the confidence that I could cut over without breaking things. The boring, risk-reducing work is exactly what a motivated human skips at 7pm on a Sunday, and exactly what costs a machine nothing to be thorough about. I got the diligence I would have talked myself out of, and without it I probably would never have made the leap because it felt too risky.

There is a second-order effect too. Once building a small thing properly gets cheap, you build other things you would have put off: a JSON Feed alongside the RSS so the Bluesky cross-poster I also built reads structured data instead of scraping Open Graph tags out of my HTML, a scaffolder for new posts, a search index. None of those were really on a list anywhere, but I had the bandwidth to build them because my comprehension of the minutiae was no longer a blocker.

The stack now is Astro, MDX, static output, on GitLab Pages. The RSS feeds are unchanged, full content and all, because that was the one setting in those 152 lines I actually cared about.

I have no thesis about whether you should use Hugo; plenty of people are fluent in it and well served by it. But the tool I could not get comfortable with was costing me momentum on the very task I had brought it in to simplify, and the price of finding out if something else might work better had dropped to one evening.

CI/CD: More Than Commit -> Deploy

Mon, 24 Feb 2025 07:00:00 GMT

This article is an entry in a topic I’m calling Reprints, where I’m collecting works that I have written in the past but published on other platforms in an effort to collect my work into a single place. Wherever possible I will be linking to currently available locations online of the original publications. In all cases there will be what I consider to be appropriate attribution and usage within either my explicit rights or Fair Use. If you think I’ve misstepped, please contact me.

This piece was originally written while I worked at Guild and published in April of 2020 on their Extra Credit tech blog.

Photo by Pablo Lancaster Jones on Unsplash

CI/CD is a central topic of DevOps. Usually, “CI/CD” is understood to mean “Continuous Integration / Continuous Deployment”. Its importance to DevOps adoption projects has led to the creation of dozens of tools designed to make that process easier. There’s lots of nuance and detail that should be part of this process, but unfortunately it’s frequently simplified down to “Commit Code -> Deploy Build”, and therein lies the danger.

Many people see that simplified process as the pinnacle of DevOps value, but lumping it all together like that can lead to problems later as your organization works to mature their DevOps practice. Why is that?

CI can be described as the process which consumes freshly committed code and runs a variety of tests and performs a “build”. Depending on the technologies involved and the maturity of the practice the details can vary widely, but at a high level, that’s pretty much it.

CD is the next step in the process, wherein that fresh build is deployed into a server environment so people can use it. Usually, this is a testing environment of some kind so the changes can be validated beyond whatever validation is done during the CI process, followed by a deployment into production.

Treating these two separate concerns as a single process prevents either of them from being as efficient or flexible as they should be. What happens when you need to move that code to another environment? In most cases, the answer is to merge those changes into another branch which will deploy there. But why would we do that? We should already have that code built and tested, why do we need to do that work and spend that time again?

How do we know for certain that the tests we performed in one environment accurately reflect what we can expect when the code is merged, rebuilt, and redeployed in another environment? If we have good automation we can be pretty sure it will be the same, but there is a chance that the merge and rebuild process could introduce changes that weren’t there before. This is especially true on teams where there are many people working fast on parallel projects. Why would we allow this risk to exist in processes that are supposed to be reducing risk as they progress?

This extra effort and risk can be significantly reduced by logically separating CI from CD, and treating them as separate processes. The most straightforward way to do that is to have the CI process create an artifact of some kind, which is then consumed by the CD process. This artifact could be a container image, a webpack, a serverless code archive, or any number of other kinds of packages that wrap up software. Whatever form it takes, the creation of this software artifact allows us to decouple the CI process from the CD process, which lets us do some pretty amazing things during CD.

It gives us much improved confidence that what we are currently deploying is the very same thing that we had previously tested. It allows us to “shift left” the risk and effort of code merges. It allows deploys to downstream environments to be faster because we’re not repeating the CI process when we don’t need to. It allows us to easily deploy the same code in multiple environments, or easily re-task an environment for testing different things by deploying a different version of some code to it. It allows us to adopt tooling around deployment that can be easily used by non-developers, eliminating developers as a bottleneck for deployments and moving the decision of “what should be where” closer to people who focus on business concerns. This list could continue, but that should illustrate well the benefits of decoupling CD from CI.

The benefits don’t stop in CD though! If we don’t have to run the CI process as often and have it be a blocker for CD, the cost of the time it takes is reduced. This gives us the space to add more thorough automated tests to the CI process, which can give us even more confidence in the build and reduce the need for manual QA later in the process.

I really believe in the value of separating concerns. If processes are designed to create bright lines or explicit handoffs between areas of concern, it makes the overall process much more powerful. Separating CI from CD is a great example of that effect, and one that I hope we will embrace at Guild as we progress in our DevOps journey. If you’d like to learn more about this space, check out Continuous Delivery by Jez Humble, it’s an amazing resource!