Migration to branches

The main difference between the new version of Balancy platform and the old one — Branches. On top level it reminds branches in systems like Git. It helps with collaborative work and versioning.

Previously users had only 3 environments - development, stage and production, and it was hard to:

1. Work simultaneously on different features.
2. Make partial rollouts.
3. Release several builds with different game balances.
4. etc

The new system with branches solves all these issues.

1. Several teammates could work in different branches on different features without interfering with each other.
2. You can release different builds with different versions on game balance.
3. During the merge process we move only changes. Previously Balancy performed only complete migration, replacing the content of target environment.

Key Changes

Migrating from the Old System

1. 3 environments will be transformed into branches with corresponding names.

2. You will have to choose which one of them will become the main branch.

   

Branches system is based on commits history, old system didn't have it. So you have to choose the main branch for your old projects, which you start working with. You will still be able to change data in 2 other branches and deploy them, but will not be able to create new branches from them or merge from/to them. That means:

1. You will have to make feature-freeze on those two other branches, making no development there, OR
2. Update your game before Branches are released, so you could select Dev branch as initial branch, OR
3. Postpone game update until Branches are released and make all process starting from the initial branch using new system.

Transparent migration

This migration shouldn't affect your current games. They will still operate as before. Json generator provides data in the same format and with the same paths, so even if you deploy dev, stage, production branches after the migration, users will be able to receive balance updates even without updating SDK.

Balance Data Bound to Branches

Previously users had only 3 environments: development, stage, production. All data was bound to a specific environment, and from time to time you migrated data between them.

With the new system you can create new branches to work with. Depending on your pipeline, the one way to work with it is Git flow, for example:

There are different options (depending on your current pipeline), you can choose the flow which fits you the most.

1. You can have main dev and master branches and create additional branches for fixes/features.
2. You can create new branch for each release
3. Etc

But eventually, in terms of UI, instead of migrating between environments you will need to merge changes between branches.

Products are Global

Previously, each environment had its own list of products, which were migrated during migration process. Now you have single global list of products, like in Apple Store or Google Play.

During branches feature release we have done some modifications in payments system — we used products from project dev environment and move it into new system. But some projects could have different list in different environments, so we added fallback to the old system as a temporary solution.

Double-check your products and store items which used them

There is a small chance that some products haven't been migrated.

User Profiles and Push Notifications are bound to environments

User's data, as before, is bound to specific environment, not branches. The same for Push Notifications.