TIL about Game DevOps: the idea of merging features to main without checking that it will break anything, cutting release branches, stabilising those, and merging the fixes back to main, which will most likely be unstable again by the next batch of merged features. The idea is that there are so many people working on the codebase that there’s no way to rely on CI/CD to ensure that main will be stable after merges. There’s just not enough hours in the day for CI/CD to run. So you don’t promise stability there. You spend your effort stabilising the release branches.

This is a complete reversal of the principals I learnt in my career, which is that main must always be production ready. Usually to allow for a release to be cut at any time (like, for example, patching an issue in prod), but also because no-one likes to checkout a broken branch. I should probably ask my colleagues that had experience in the game industry about this, and see how well it worked for them.

Follow up

Talked to my contact about this. He says that this is indeed a thing, and that main would usually be unstable because CI/CD runs would take too long. The reason, which I didn’t consider, is that the entire team is working towards a single artefact and it’s difficult splitting it out into separate repositories with their own CI/CD. But he did make the sense that it hated this form of working. It got so bad that one of the senior devs would need to spend every morning just stabilising main.