Branching in Multiuser Development

Branching is a further refinement of the merging development process.

Branching can provide higher efficiencies over large development teams that have overlapping releases, but it requires significant administrative overhead.

This section contains the following topics:

About Branching

In branching, developers work on private branches to isolate their code from other developers and merge changes back to the main branch.

Different strategies can be followed, depending on the size of the development team.

In the Simple Development Model, all development occurs on a single main branch. This strategy has the following characteristics:

  • Only for emergency fixes

  • Checkouts might not be the most current code

  • Carries a stability risk for the mainline branch

The figure shows the Simple Development Model.

Description of GUID-C93A2999-9FF4-415E-ABF4-FC494F2BD0E2-default.gif follows
Description of the illustration GUID-C93A2999-9FF4-415E-ABF4-FC494F2BD0E2-default.gif

In the Small Team Development Model, development occurs on a single Dev branch, with a separate Main branch strictly for releases. This strategy has the following characteristics:

  • The Mainline is the official release branch

  • Development occurs on a separate branch

  • Stable code is merged back to Main at key milestones

  • Branches are synchronized periodically

The figure shows the Small Team Development Model.

Description of GUID-F05AF90B-B332-4C87-9F5A-0F1D1B437964-default.gif follows
Description of the illustration GUID-F05AF90B-B332-4C87-9F5A-0F1D1B437964-default.gif

In the Multi-Team, Multi-Release Model, development occurs on multiple Dev branches, again with a separate Main branch strictly for releases. This strategy has the following characteristics:

  • Supports more efficiency over disparate teams

  • Development occurs on separate branches

  • Stable code is merged back to Main at key milestones

  • Branches are synchronized periodically

The figure shows the Multi-Team, Multi-Release Model.

Description of GUID-6BE98935-17B5-44EA-99C6-4B494E93F7BA-default.gif follows
Description of the illustration GUID-6BE98935-17B5-44EA-99C6-4B494E93F7BA-default.gif

Using the Multi-Team, Multi-Release Model in Oracle Business Intelligence

Using complex branching strategies in Oracle Business Intelligence requires attentive organization of repository files, as well as altering the Multiuser setting in the Oracle BI Administrative Tool.

The following provides an overview of the required steps.

  1. Create a Main repository (Master Repository) and store it in the Master multiuser development directory.

    • Projects must be explicitly defined.

    • Branch developers should not have access to the Master directory.

  2. Create a subset of branch repositories by extracting from Main and storing them as the Team1 and Team2 multiuser development directories. The Main and Team RPDs must be stored and secured in separate directories on the network.
  3. Developers must check out, develop, merge, and publish from their respective Team RPDs. Developers A1 through A3 and B1 through B3 should manage their metadata work and merge to their Team repository.

    • Teams 1 and 2 must maintain their own repositories and periodically synchronize from Main to Team branches.

    • The Team repositories must be merged back into and published in the Main repository.

  4. One specific group, for example, release management, should manage all project definitions, perform merges, publish, and synchronize the Team RPDs back to Main.

Synchronizing RPD Branches

For large development teams, it is a good practice to perform periodic branch synchronization as Main changes, in order to ease the ultimate Team publishing step.

Use the Administration Tool to synchronize repositories in a three-way merge.

  1. Publish all changes from your Team development branch and open the repository (RPD) in the Administration Tool. This the current repository.
  2. Extract a fresh Branch subset from Main. This is the modified repository.
  3. In the Administration Tool, select File, then select Merge and browse to the backup of the previous Branch subset. This is the original repository.
  4. Resolve all issues and perform the merge.

    The RPD named in the Save merged repository as field becomes the new branch development RPD and is called the Original in future synchronizations.