CCD Addressable Setup

Hi there,
We have been using UCB for a few years now but just switched to the Addressable System and Unity CCD for our current project:
There seems to be a lot of outdated information going on in the official documentation pages and the lack of proper tutorials and/or guides/best practises does not help.
So I just wanted to go over our expected setup quickly and see if anyone spots any obvious errors/potential issues on how we handle this.

We are pretty much trying to replicate a similar slightly simplified workflow as shown here by the way:

Unity Cloud Build
Every platform has (at least) 2 build targets: Development and Production that build the player.
- Development runs continuously on every push (GIT)
- Production is "manually" triggered on very specific commits through Jenkins
- Additionally each platform has a "Content-only" build target that is supposed to update the CDN data only

Now with that being said, from what I understand it does not make sense to have "Content-only" build targets for the "development" as Cloud Build requires to re-build the Addressables every time there is a new build?
---> You can have multiple content-updates but only one build(?) <---- (taken from a different thread)


CCD
3+ Buckets for each platform (Development, Staging, Production)
Content from dev moves into staging for QA and then into production "manually"

It looks like all official Unity tutorials (plus all third-party ones) always use one huge shared bucket for all platforms so my question is:
Do we *have* to use e.g. RemoteConfig on the client(s) to grab the correct bucket for each platform or is there another way I haven't seen yet that allows us to set this up in this specific way?

 

Looks like... you CAN make a completely new build using "old" remote addressables...? I thought this behaviour was not supported?
Could someone confirm/deny this please?

 

Thanks this is very helpful already! This whole topic is very advanced for sure but sounds like we are on the right track. Having someone from the Addressables team confirm this would be super helpful, thanks!

 

I'm not sure I totally understand the question, but I'll give what answer I can. Addressables content is built as a separate step from building the player. This build includes all local bundles, all remote bundles (if any), a local copy of the catalog, a remote copy (if enabled), and some core settings info. That core settings info knows things like where the remote catalog is.

After you've built content, you can build the player all you want and it'll be fine. If what you are describing is:
1. build content
2. build player v1
3. change content
4. rebuild content, but don't upload
5. build player v2 and hope it'll work with the original content
This is a little more tricky. It could work. It depends on what all you changed. If the new content is the same as the old, you're fine. If the new content is different, you might be fine, or not. In this situation you'd have a player with new local content and old remote content. Are they compatible? Is the old catalog on the server going to understand the new local content?
Maybe is the answer to all that. Setting up your group setting to not include hash of content will help (so bundles have the same name despite new content). Similarly avoiding hard dependencies between remote and local content will help. All in all, it could work, but is potentially fragile.

Though again, I'm not 100% sure what you are asking, so I could be answering the wrong question.

 

Thanks, this is actually what I wanted to know. It will come down to our internal architecture and further planning to see if it will work out like this.
I read in some other thread that it does not work with new player but old content so thanks for confirming!
I am definitely going to follow up in a bit with our new setup

 

Hi I thought this was such an amazing video!

I've been using CCD and loving it as well as addressables. At the moment I'm using 1 bucket, but I'd like to start using more buckets to help with testing before moving to production.
I hadn't thought about changing the buckets URL using Remote config. That's a genius idea, I'd love to get a tutorial or some steps to understand how to achieve this. I'm not sure how to change the addressable config URL from the remote config data. That seems to be a missing step for me, which was not quite covered in the video.

Any help would be really appreciated on connecting the remote config data to the addressables url at runtime and changing it depending on device/use ID idea to help test for different buckets for different users would be great.

Thank you!

 

Thanks for the reply. I managed to see that thread a few days ago. Also followed it and got it working.

Works really well.

If you could expand on it with further tutorials that involve badges for version etc that would be great.

Thanks for all the information and hard work

 

Can you give a list of steps to follow starting from scratch that allows us to upload a prefab to CCD and instantiate that prefab using the Addressables system in code?

 

Cool Thanks!

 

Hello,
I am setting CCD on our project to host our addressable bundles. One thing I'm a little confused about is that (assuming I use the same setup than this video) when I promote a dev release to production, although my production binary can find the catalog file in the bucket, the urls for the bundle themselves will still point to the development bucket. If I push a new release on production, at best I update all live bundles to the production one, at worst I break everything.
What is the intended way to use the release promotion system with addressable? Getting curly braces values in the loading path that get set by remote config ?