Branching

Omnata has been designed from the ground up for robust change management, with configuration branching strategies to match a variety of common scenarios.

These branching features are available when you enable branching for a sync.

Branching in Omnata is similar to branching in git, which is why we borrowed the term. But there are some differences, described in more detail beneath this page.

Branching is available for both inbound and outbound syncs, but naturally it works quite differently in each case. See the pages beneath this one to learn more about each.

That said, there's a key ground rule that's important to keep in mind:

The main branch is always production

People use git branches in a wide variety of ways. Omnata branching is much simpler and restrictive (in a good way).

Every Sync has an implied "main" branch, which is for the production usage of the app (the part that impacts day to day business activities). All branches diverge from this branch, and lead directly back to it.

What's included?

Settings that must be applied via a branch merge:

• Sync parameters, except for any branch-specific overrides

• For outbound syncs, field mappings

• For inbound syncs, stream configuration

Settings that are allowed to differ between the main sync and a branch:

• Branch-specific overrides to sync parameters

• For outbound syncs, the source database, schema, table or id column. This is to accommodate test tables of an identical schema populating test environments. When merging, a check will be performed to ensure that any schema divergence in the branch table is compatible with the schema in the main Sync. For example, if you add a new column in the branch's table and map a field from it, the new column will need to be present in the main table before merging. Note: you can directly re-home a source table on the main sync if you've moved it to another location, but the same schema check will be done.

• Sync warehouse

Settings that are branch-agnostic and applied immediately and directly to the main sync:

• Sync name

• Sync description

• Sync schedule (note that branches never run on a schedule and must be manually triggered)

Why can't field mappings also have Branch-specific overrides? Frankly, we think this would be a bridge too far.

Once you start changing what a record's payload looks like, the risk when merging the change increases and begins to undermine the whole point of testing.

Branch status state machine

UI driven schedulers (Omnata, Dependent Sync)

dbt scheduler