Trunk Based Development: Prevent unreleased assets and features from being included in the build

Question

Our team is currently working on a live service game (A game that will be updated regularly post-launch) and is using a trunk-based development strategy.

The trunk-based development strategy is great. But the only issue is that it's incredibly hard to prevent future content (i.e. UI graphics, game assets) and features from being included in the build before its official release. This is not ideal, as players are now decompiling the game and extracting the WIP UI assets and peeking the game code to figure out future update contents.

The issue is easier to solve on the code side, with conditional compilation flags as feature toggles. But for content, especially content that could not be self-isolated (e.g. a new UI element that lives on an existing screen), it's very easy to get accidentally included in the final build.

How do other game dev teams prevent this issue?

Is there any better branching strategy, better version control tools, or some architectural pattern that could prevent this issue from happening?

(FYI, we are using Unity + Git for development. The solution we have come up with is to put these assets in addressable and label them with a specific feature flag. In a build script, we will remove all addressable with feature flags that aren't enabled in the current build. As for content that lives on existing UIs, we have two different versions of addressables labeled with two different flags, each only differs on the modified UI elements. As you could imagine, this is very time-consuming to set up and is very error-prone.)

Answer 1

It appears that what you need are more branches. At least one for development and one for each released version.

The release branch for each version would diverge from the main branch whenever you make a major feature release. That release branch would then be used for hotfixes which you need to get online quickly, but which don't add any new features. Those fixes would get merged back into the development branch as soon as feasible, but priority would be to ship them quickly.

You can do that while keeping the "trunk" workflow for working on the development branch. While the release branch is being used for hotfixes, the development branch would be the actual "trunk" on which all the new features get developed. When you make a new feature release, you would merge any still remaining commits from the current release branch to the trunk and then create a new release branch for going through QA and deployment and which will then be used for supporting the new version post-release.

Should you transfer to a "flow"-based approach for development? That depends on how many features you are developing in parallel and how well you are able to plan and execute on your release schedule. When you usually have no problems with completing all planned features before the release deadline, great. But when you frequently have situations where just before release some features are finished and some are not and delay the release, then you might want to switch to the "flow" model where each new feature is being developed on a separate branch.

The flow model has the advantage that you are free to develop each feature in isolation, without polluting the main branch with half-finished stuff. When you want to make a new feature release, you look at each feature-branch and decide whether or not it's ready to merge it into the main branch. Those which are not can wait until the next feature release. Those which are ready can be merged into the main branch. Then you create a new release branch from the resulting main branch, and send the release branch down the QA and deployment pipeline.

The disadvantage of the flow model is that because you are developing each feature in isolation, it can be difficult to make sure those features actually work well with each other. When two features are fundamentally incompatible with each other, you often don't notice until you try to merge them into the main branch.

Which model is the right one for your project and your team? That's up to you to decide.