Just a quick note to record that, for the first time, I’m taking part Advent Of Code - a series of programming challenges that run every day from the 1st to the 25th of December. Inspired by my experiences during Exercism’s 12in23 challenge, I’ll be trying to complete the challenges in Rust (see my solutions here). That’s on top of trying to complete Exercism’s “December Diversions”, as well as 5 challenges in another language for the year-long badge to make up for the fact that January was unassigned (and keeping up my reading of Ward to remain on-track to finish by the end of the year).

It’s fairly uncontroversial that, for a good service-deployment pipeline, there should be:

• at least one pre-production stage
• automated tests running on that stage
• a promotion blocker if those tests fail

The purpose of this testing is clear: it asserts ("verifies") certain correctness properties of the service version being deployed, such that any version which lacks those properties - which “is incorrect” - should not be deployed to customers. This allows promotion to be automated, reducing human toil and allowing developers to focus their efforts on development of new features rather than on confirmation of the correctness of new deployments.

As I’ve discussed before, this blog is hosted on a k3s cluster which runs on 3 Raspberries Pi in a nifty little case. The router that powers our home network is in my partner’s office, with the Pi cluster nearby so that it can benefit from a fast stable wired Ethernet connection.