Branches

Introducing Branches & Versioning system, the workflow which allows you to work with your game data/configs in Balancy in a Git-like way. Old environment-based workflow had a lot of limitations.

With branches, you can:

• Work on different game features simultaneously: one game designer can work on battle pass in feature/battlepass branch, while another one - on in-game quests in feature/quests branch without interfering with each other. And later they can merge all changes into main branch.
• Move changes between branches without replacing or discarding changes in target branch.
• Version your releases to run multiple builds with different game balance simultaneously.

Migration to branches

Read additional notes to migrate from the old environments-based workflow.

Branch Creation

Currently selected branch is shown below Project Name.

All other existing branches are available via dropdown menu from this selector. On the Deploy page you can create a new branch from the current one.

The following UI will allow to set up the new branch settings:

It will be the copy of the current branch. After that you can make changes in this branch without being afraid of breaking something in the original branch.

Typical Scenarios

Let's see some typical scenarios which would be possible to implement from now on.

Setting Up the Initial Workflow

This scenario demonstrates how the old system with 3 environments will be possible to keep working.

1. From initial dev branch, create new branch for QA on stage environment. Then, create new branch for releasing game on production environment.
2. Make some changes in dev branch, merge them into stage branch for testing, then merge them into production to release new update.
3. Repeat the step 2 for every new update you want to release.

Supporting Multiple Game Versions

This scenario demonstrates how it will be possible to support multiple versions of the app at the same time. The most common use case - partial rollouts.

1. From initial dev branch, create new branch for a new version of the game. Create new branch from it for QA on stage environment, then create new branch for releasing new version on production.
2. From the last dev branch, create another new branch for the next game version. Create stage and production branches in the same way according to the workflow.
3. All production branches are available for game apps of the corresponding version at the same time.

Performing Hot Fixes to the Released Game Versions

This scenario demonstrates how it will be possible to make hot fixes for already published versions.

1. Having some production branch with some game version you need to fix, create a new branch on dev environment
2. Make all necessary changes in this hot fix dev branch
3. Create a new stage branch from this hot fix dev branch for required QA
4. Merge approved changes from stage hot fix branch back into production branch.

Parallel Feature Development

This scenario demonstrates how it will be possible to develop different features in parallel.

1. Having some dev branch, create new feature branch on dev environment to work on a new feature.
2. Make changes in both dev branches as long as you need, making deploys to test your work.
3. Merge new feature from its branch into main dev branch to gather all changes before sending for QA.

Versions & Environments

Pay attention to the branch settings:

• Version
• Environment

Depending on these parameters and real build version (you set it in Unity) our SDK determines which branch to use for this game build.

Versions intersections

Keep in mind, that there could be versions intersection between two branches. The SDK will use the branch on required environment with the highest available version, which is less or equal to the current build version. For example, let's say you have 2 branches:

1. Branch "release-1" with build version setting 0.0.3
2. Branch "release-2" with build version setting 0.0.5

If your current build version is 0.0.4, SDK will use "release-1" branch. If your current build version is 0.0.7, SDK will use "release-2" branch.

Branch Flags

With new flags in branch settings it is now possible to hide branches from dashboard, if you don't want them to be always present in the list, and also to control if a branch will be generated in JSON file or not.

Hide From Dashboard: Hides this branch from the branches lists in the Navigation Panel and when merging branches. It will still be possible to directly enter the branch through its URL. Hidden branches could be reverted back to visible via Hidden Branches list, available at the Deploy & Branches page, if there is at least one hidden branch in the project.

Don't Generate in JSON: Prevents this branch from being generated in JSON when deploying. If this flag is set, the game build will not know about this branch and will not be able to connect to it.

Data Migration

You can merge changes from one branch to another.

In this scenario all changes (only changes) from source branch will be applied on top of the target (current) branch. In most cases there shouldn't be any problems. But if the same items were changed in both branches, you can face conflicts.

Resolving Conflicts

There could be situations when you change the same items in both branches, so there will be conflicts. For example:

1. The same document was changed in both branches.
2. The same template or its parameters were changed in both branches.
3. etc

You are able to see the list of all these items and decide if you really want to merge these branches.

For example:

1. You have Gold store item in both branches.
2. In source branch you change it into copper.
3. In target branch you change it into silver.
4. After merging of source branch into target branch, silver will be replaced by copper.

In this case you can lose some changes you made in target branch, because changes from the source branch will be applied on top of them. Currently, changes in source branch have higher priority over target branch.

Later Balancy will improve conflict resolving procedure, so it would be possible to manually select which values to apply during conflict resolving.