Better way to manage Unity content update???

[Trung-Hieu]

We are using Addressable@1.2.4 for our project (already live). The project requires backward supports for earlier builds, as there are about 2-3 production build versions at any time that are still being used.

Currently our build workflow is at follow:

• To make a new build, from a stable branch, checkout to a new deploy branch (i.e: deploy/android/v2.1.15). Build the initial content there and upload to remote server. Commit the addressable_content_state.bin file to the branch to save it for future content update. Then build the game binary and upload to the store. ( #1 in the picture )
• To do a content update, merge the stable branch into the appropriate deploy branch. Run the “prepare for content update”, which may generate some new content update groups. Then run “build for content update” and upload the new bundles to remote server. Commit the addressable group layout changes to the deploy branch after that. ( #2, #3 in the picture).

However, after the addressable group layout has been changed in the deploy branch, we find it hard to merge from stable into deploy again for another content update ( as in #4 in the picture), due to the addressable layout on both side is significantly different. The problem is due to the stable branch does not have any content update group, while the deploy branch may have some due to #3. The proper merge resolution requires manual guid compares / copy-paste across files and that is so painful that we resorted to manually replicate our works on the deploy branch itself.

We tried skipping the commit at step (3) (i.e: prep and build content updates, but do not commit the new addressable layout). However, we cannot do any further content updates, presumably because of skipping the commit??

Just wondering how do you guys manage content updates for multiple versions? Is there any recommended approach for this problem from the Unity addressable dev team?

[Favo-Yang]

This is a very good and detailed question. I really appreciated if other folks share your best practice.

My 2 cents,

Option 1, do not use content update. Content update (or update restriction) is designed to update those “cannot change post release” assets. If you have lots frequently update stuffs, simply use non-static group (“can change post release”). For each releases, you can build just once, deploy to server, and all existing clients will get update to the new release. Depends on how you slice the bundles (group + bundle mode), existing clients may only need to download the changed bundles.

Option 2, use content update, but manage it in the stable branch. After a few content updates, ends up with lots .bin files and content update groups (1-N) in your stable branch. You can directly build from stable and push to server, thus, don’t need to merge to release branch at all. It has certain drawbacks though.

Option 3, keep what you did, leave your stable branch the cleanest state, and manage content update in release branch. However to avoid conflicts you need develop a smart merging strategy. The idea is always use the stable version to overwrite the release branch version (conflict solver: use stable branch), then you run a script to remove duplications, before prepare for next content update. For example,

1. the first merge, stable branch is same as the release branch.

stable branch:
default group > asset-a
release branch:
default group > asset-a

2. add asset-b, the second merge, the prepare for content update.

stable branch:
default group > asset-a, asset-b
release branch:
default group > asset-a,
update group 1 > asset-b

3. add asset-c, the third merge (conflict resolver: use stable branch)

stable branch:
default group > asset-a, asset-b, asset-c
release branch:
default group > asset-a, asset-b, asset-c
update group 1 > asset-b

now the key part, run your fix script, find all keys in update group, remove them from default group (asset-b).

release branch:
default group > asset-a, asset-c
update group 1 > asset-b

then, prepare content update…

release branch:
default group > asset-a
update group 1 > asset-b
update group 2 > asset-c
(this is what we want)