In my previous devlog I talked about how I am a big fan of Continuous Deployment and how it means there’s always a single, safe version of the game that can be deployed to production. I also described that there are exceptions to the rule, like sometimes using a (relatively short-lived) feature branch to work on something that can’t be broken down into smaller tasks.
For AirlineSim in particular there’s another perpetual exception. Or maybe not an exception but rather an “unfair advantage”: There’s only one developer on the project. Consequently, having everything on a single branch obviously becomes a lot easier and safer. In teams with more developers, what I did in week 17 would be an absolute no-go!
But here’s what happened: As described last week, I finished the footer component and shipped it to Paine. I knew that it wasn’t 100% finished, because one part of it - the game time clock - required information about the currently selected airline to render the time according to the airline’s time setting and hub timezone. This wasn’t a big thing and I implemented the respective changes early last week so I could deploy it to Paine, do a bit of testing and then wrap it all up for a maintenance patch and the Quimby relaunch on Wednesday.
Shortly after I pushed the changes, I got a notification that the build pipeline failed due to a few failed tests. I didn’t think much of it, that’s what the pipeline is for, after all. At first inspection, it looked like a so-called “flaky test”, a test that fails sometimes but not always. Something that should be dealt with as quickly as possible because it erodes the trust in the test suite. The problem with these sort of failures is that they often really hard to troubleshoot. It’s in their very nature that they happen sporadically, seemingly without a clear cause. It was no different in this case, where the failures occurred reliably, but only on the build server, not on my local environment.
Long story short: It took me the better part of 3 days (!) to resolve the issue. Almost 3 days with a broken pipeline…the absolute no-go I referred to above 
. In a team with more devs, this would have blocked everyone else on the team.
On Thursday I decided to cancel the maintenance patch and only relaunch Quimby to not increase the delay even further. I won’t go into the technical details of what went wrong. Just the crucial bit: Effectively, it was caused by static references in legacy code that weren’t a problem before but started causing issues in a new test setup I started using for the gen-3 backend. At the end of the day, the problem forced me to finally get rid of these references, at least on the code paths required for my new tests. Remember: Static code is bad (also see devlogs 2024-22, 2024-31 and 2024-35, among others 
).
Week 18 is going to be a short one for me (due to private things and Labor Day on Friday), but I’ll try to finally get that maintenance patch out the door.