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.

moondory77

@Paul-Winterhalder Thank you for your response.

To provide more context on our current architecture, we utilize CustomEntities by assigning one collection per tournament (e.g., WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT for the Week 7 tournament). Each of these collections then contains multiple records, which store the meta-information for the division groups within that specific tournament.

We adopted this structure to dynamically create and manage the required number of division groups for each weekly tournament with minimal overhead.

If we were to manage these as individual records within a single collection as you suggested, we would need to implement additional indices to distinguish groups by week and perform extra queries for every update. We specifically chose to manage them as separate collections to simplify this logic and avoid unnecessary complexity.

Given this workflow, moving to a record-based management system would significantly increase our implementation's complexity.

With that in mind, would it be feasible to add an option in the Deployment settings to include or exclude specific CustomEntity collections from the migration? This feature would greatly help us maintain our current efficient workflow while safely deploying other configurations.

Paul Winterhalder

Hmm - deployment is a very complex process - and in this case the complexity of picking and choosing what collection definitions get migrated over outweighs the complexity you would have to add a new field "week" to your collections and queries.

So apologies - but you should make the appropriate changes so that you have a "week" field in your collections (with appropriate indexes).

In compensation - I can offer up that:

We ARE adding the ability to exclude Division Set Configs from deploys (as you requested) <-- this should be available next week sometime.
And we DO now support migrating META data WITHOUT SCRIPTS via the builder API... (that got patched YESTERDAY!)

I hope you can understand.

moondory77

Thank you!