When working on my personal projects, I typically just push straight to main - opening a PR just to approve it seems entirely pointless, as if I had been able to find any issues in my own work, I wouldn’t wait to do it in a PR! However, this does mean that, if I forget to run any quality checkers (linters, tests, etc.), I won’t find out about it until on: push GitHub Action runs, and even then I might not see the failure until several commits later.

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.

I just added a process to my blog deployment pipeline to block the deployment of any blogs that contain the characters “T​K”.

Observant readers of this blog, refreshing every day desperate for new content, will have noticed that the last blog post - dated 2022-12-31 - actually went live in the middle of January. My k3s cluster, which had always been a bit rickety, finally gave up the ghost in late December, and two of the nodes needed to be fully reimaged before I could start it back up again.

Since leaving Amazon ~4 months ago and dedicating more time to my own personal projects (and actually trying to ship things instead of getting distracted a few days in by the next shiny project!), I’ve learned a lot more about the Open Source tools that are available to software engineers; which, in turn, has highlighted a few areas of ignorance about CI/CD Pipelines. Emulating Julia Evans, I’m writing this blog both to help lead others who might have similar questions, and to rubber-duck my own process of answering the questions.