Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Question Unity CCD deployment best practice?

Discussion in 'Unity Cloud Content Delivery' started by dnnkeeper, May 22, 2023.

  1. dnnkeeper

    dnnkeeper

    Joined:
    Jul 7, 2013
    Posts:
    84
    I'd like to discover best practices for mobile application deployment using Unity CCD services and addressables. I can't figure out what workflow we need to establish to prevent errors and keep the ability to update content for our application without updating a published apk version and vice versa.

    I find this system very confusing.

    We'd like to deploy in 3 phases: development, staging, production.

    Let's say we have 3 corresponding environments:
    dev, staging, production

    In the dev environment we'd like to work on different features in parallel. So we have different buckets for each feature branch that devs build and test by themselves. This works fine but makes the environment a bit cluttered.

    Then we merge our branches and produce a release candidate. Its content is uploaded to the staging environment. We'd like to test and seamlessly promote it to production. But the remote catalog path is built in the application, so when promotion happens there is no way to change the path to the bucket and the only option is to build another apk with the production profile from the exact same sources. It is an error-prone practice.

    Also if we upload new content to the production bucket already published apk can stop working. But sometimes we'd like to update the production bucket with the new content that is compatible. How do we track and control this compatibility?

    One option I found is to get rid of the staging environment and replace it with the badges in the production environment bucket. So that every app version has a corresponding badge that can be assigned to the latest compatible content (compatibility we track manually). But this leads to a rapid badge count growth and also might be prone to an error. Is it a good practice? Or is it better to bind every apk version to its own bucket and promote compatible content to it?

    Also, I have some minor concerns about content growth in buckets. Every release changes some bundles and adds a new catalog with a timestamp. Should I remove all the content from the bucket before updating it?

    Should I get rid of the timestamps and hash filename additions in bundles to prevent outdated content accumulation in buckets or this can break updates due to client-side caching?

    Also, I can't understand what happens when I change some code and hit 'build&run'. I have 'Build Addressables on build Player' option enabled and a remote catalog generation. Every time It generates a new remote catalog with a new timestamp so every time I have to re-upload addressable. I can set 'Player Version Override' string that overrides it. Is it the correct way to update an app and content separately?
     
  2. TS-Trooper

    TS-Trooper

    Joined:
    Apr 30, 2019
    Posts:
    20
    Hi DnnKeeper.

    I am trying to find out the same thing. Did you ever get an answer to your questions?
     
  3. p0w1nd

    p0w1nd

    Joined:
    Oct 28, 2015
    Posts:
    141
    Same concern. Anyone can help answer? Thanks!