As I’ve mentioned once or twice before in my devlogs, I’m a firm believer in Continuous Delivery (CD). This means I do all code changes on the main branch in version control, contrary to dedicated feature branches for each - well - feature. Whenever I commit a change and push it to our version control server, it immediately triggers a pipeline run. The pipeline rebuilds all the assets and artefacts, runs the complete test suite, and deploys a new snapshot version to Paine and our internal test servers. A deployment to production game worlds uses the exact same process, just that I tag the latest commit with a version number.
This might appear risky, and in a way it is. But the huge advantage of this process is that one tries to keep changes small and self-contained. There’s a strong motivation to have proper test coverage so one doesn’t accidentally ship broken code. One can deploy a hotfix or any other type of smaller update at any point in time without having to “switch branches” or worry about conflicting changes that might exist on any other branch. That’s because (most importantly) there’s only a single source of truth for the code base: The main branch or “trunk”, as it’s often called. There are no two, three or more different version of AirlineSim floating around. There aren’t dozens of feature branches that, once merged into the main branch, might cause merge conflicts or (even worse) unintended behaviour changes due to “two different realities merging”.
This approach works surprisingly well for a lot of things, even major features that take years to develop. Think the new Distribution System or Aircraft Performance 1.5: Technically, their code exists in all game worlds, but it’s only enabled in Paine or internal test servers. Feature flags and “shadow releases”, while adding a bit of complexity overhead, not just help a CD process, but can obviously be used down the road to make the game configurable for all sorts of purposes.
Here’s the but: There’s no rule without an exception. Sometimes, work on a feature is impossible (or very hard) to break down into self-contained, non-destructive changes. Then there’s no way around a “feature branch”. And one such example is my work on the seemingly tiny and harmless “footer” you see on all pages. I touched on this last week, but a quick recap: The gen-3 UI will eventually be used to build complete pages for new or rewritten features (the first one will likely be the new DS search interface). But a lot of components (like said footer) are shared between all pages, including for 20 year old gen-1 features. So I am working on a way to have a single part of the code to generate these components across all three framework generations. So although the footer is very tiny, it requires the full-blown framework to render data based on the authenticated user, their in-game preferences, their selected airline and so on. Since I can only change the whole footer or nothing, I opted to go with a rare feature branch to not break any emergency builds I might have to do before I was finished.
Fortunately, said branch was short-lived and I merged it towards the end of week 16. Some finishing touches and the code base should be back in a release-ready state for a maintenance release (planned for) later this week.