Question Managing large numbers of asset bundles

I've got an app right now that is essentially just a shell and then utilizes asset bundles to download specific content as needed. Due to the nature of the app, I could have thousands of different asset bundles if things go well and it's popular.

The main shell contains all of my code, while the asset bundles themselves are around 80 MB each when downloaded. Due to it being the only way to have a usable workflow when creating the assets, each bundle is split up into a different project, has a bundle built, and then that shell application loads the bundles as needed.

Obviously, this means I have a single code application, and the workflow means that when the code changes, it then needs exported to all projects that later create the bundles so that the code functionality exists when everything is built.

However, when releasing periodic updates, since code needs to change frequently as new features are added, this gets into issues of creating messy testing environments, even with automated testing, and an ever more complex build process.

Is there a better way to implement asset bundles to accomplish this? Or, should I potentially be looking into a different system? One of our other developers had looked into Addressables at one point but was of the opinion that for all of it's flaws, asset bundles made more sense for our use case (though I don't remember why he came to that conclusion off hand).

 

I can't understand your mean completely. I noticed ""However, when releasing periodic updates, since code needs to change frequently as new features are added, this gets into issues of creating messy testing environments, even with automated testing, and an ever more complex build process."". When you release certain version, you can
generate a list which contain the certain asset bundles version. For example, you release version is 1.0.0, and for version 1.0.0, asset bundle version(this contain a list of asset bundles) is 1.0.0 also. In code, you can check the asset bundle files is right or not and update asset bundle file.

 

How so? You're saying treat all of the code as package versions and set the bundle to use a specific version?

How would that actually build, because if I understand you correctly you're saying something like:
Main app - Has code for versions 1.0 and 1.1 in it.
Bundle A project - Uses code for 1.0.
Bundle B project - Uses code for 1.1.

But, that main app containing both 1.0 and 1.1 would run into a whole bunch of issues from having duplicates of classes in it wouldn't it?

 

Certain App just contain certain code version. If situation 'Main app - Has code for versions 1.0 and 1.1 in it.' need split many different features as different module. Each module has it's own code version and resource module(Asset Bundle) version.

 

I don't think that works, because AssetBundles don't contain code do they? All the code needs to be included in the main application? So if I were to give each Unity project a different set of package versions, as code is added, updated, or removed, it would result in situations where components simply no longer exist, and when components differed, there would also be a lot of issues where GUID's no longer match up and scripts wouldn't be found.

Is this just an incorrectly set up workflow?
Project A - Code app, minimal additional assets.
Project B - Content, contains all runtime code from Project A exported as packages and then imported.
Project C - Content, contains all runtime code from Project A exported as packages and then imported.
Project D - Content, contains all runtime code from Project A exported as packages and then imported.

Then Project A is built and run, and asset bundles built from projects B, C, and D are downloaded/cached and run. If we make large updates between projects C and D on our side, there's not a way to use version 1.0 code on projects B and C, with project 1.1 code on project D it seems because if project C has code that has been obsoleted between versions 1.0 and 1.1, it will cause errors.