Request for Granular Migration Options in Deployment (Excluding DivisionSetIds)

moondory77

Is it possible to perform a more granular migration when deploying leaderboard configurations via Admin Tools > Deployment?

We currently manage three environments—Development, Staging, and Production—all of which utilize identical Leaderboard and Tournament configurations. However, we are encountering an issue with DivisionSetIds. Since these IDs are generated dynamically based on the number of participating users during each rotation, each environment ends up with different DivisionSetIds.

Because of these discrepancies, we are unable to deploy leaderboard configurations from Development to Staging or Production using the standard Deployment options. Manually syncing these configurations is not a viable solution as it poses a high risk to our live service.

Is there a way to deploy leaderboard configurations while excluding DivisionSetIds? If not, could you provide a recommended workflow or consider adding this as a feature to the deployment tools?

JasonL

Thanks for your suggestion, we will review it...

noah

hi. braincloud team.
I previously requested improvements to the deployment process via email.

I'm running three apps and managing deployments, and I'm experiencing a conflict with the DivisionSet.

For management purposes, I'm developing in a single dev environment and deploying to a staging/production environment.

Can you help me resolve this issue quickly?

Paul Winterhalder

Okay - to start - you really should be updating to Production ONLY from Staging.

That said, your challenge is due to the fact that your app is dynamically creating new Division Sets based on the results of previous tournament rounds.

Do not overwrite Leaderboard, Tournaments, etc. configurations" would allow you to deploy without updating any of Leaderboards, Tournaments and Division Sets.

That said - if you DID want to update static Leaderboards and Tournaments - but NOT the dynamically generated Division Sets - then we don't currently have an option that separates those.

We can look into adding a new option that accommodates this:

Do NOT overwrite Leaderboard, Tournaments, Division Sets configurations

Do NOT migrate Division Set configs <- if above is unchecked, then this one is selectable. If above is checked, then this one is unselectable but checked by default.

Would this new option give you what you are looking for?

Paul.

moondory77

@Paul-Winterhalder. That is correct. If that option is available, it will work exactly as we intended. Thank you!

I have one additional request regarding the Deployment process.
Currently, when performing a deployment, we can select "Don't Migrate" for CustomEntity instances to prevent them from being moved. However, it appears that Collections are always automatically copied during the deployment.

Would it be possible to provide an option to choose whether or not to include Collections in the migration, similar to the functionality for CustomEntities?

Paul Winterhalder

HI @moondory77 - you mean an option to not even include the custom entity collection definitions? What is your use case for that?

Paul Winterhalder

Ah - I think I see what you are doing.

Instead of constantly creating and deleting collections - why not just create the tournament config records (objects) - and then delete them. If just take the nameing convention you are using (i.e. "WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT") - and made that part of the of the record instead - you wouldn't have to keep creating and deleting whole collections.

And you can just set a TTL for the records themselves - so that they clean themselves up after 10 days or so.

Paul.