Working in branches

Branches allow developers to work in separated areas, which helps avoid the problem of overwriting someone else's changes and minimizes the occurrence of conflicts and errors. When a developer or developers make changes in a branch, these changes have no effect on other branch rulesets or base application rulesets. As a result, developers can work on multiple features in parallel, even if the features use the same base rules. This saves time and accelerates application development.

As a best practice, to start branched development, create team applications by copying your base application. When every team has a separate application, implementing and testing changes is more convenient compared to a scenario in which multiple teams work on the same ruleset in multiple branches. For more information, see Creating a development application.

When the development is complete, teams merge changes to the base application. By merging, developers can select only those changes that they intend to implement in the base application, and discard other rules. Merging provides greater control over changes that developers implement in the base application. For more information, see Merging branches into target rulesets.

Working in unlocked rulesets

Unlocked rulesets are available to multiple developers at the same time. When developers work in an unlocked ruleset, the implemented changes immediately affect other developers who use the affected rules in the same ruleset. This approach might lead to work overwrites, errors, and unexpected results. A solution to minimize the risk of overwrites is rule checkout. When a developer checks out a rule, the rule is unavailable to other developers for editing. However, after implementing their changes, a developer checks in a rule, and only then do the changes affect other rules in the ruleset. For more information, see Checking out a rule and Checking in a rule.

Application development for larger projects

The most common scenario is application development that involves multiple teams working on multiple features. In such scenarios, branched development is the most suitable choice. Developers can implement changes simultaneously, because changes in one branch have no effect on other branch rulesets, which minimizes errors and work overwrites. Parallel development of multiple features saves time and helps developers create software faster.

Branched development involves merging, which developers can use to select rules to include in the base application, and remove unnecessary rules. Also, validation of new features in an environment that does not include the ongoing work of other developers is more effective and reliable. With branched development and merging, the process of reverting changes is easier than when teams work in unlocked rulesets. Merging is also applicable in situations in which changes require approval, for example from a manager or a team lead.

Rule checkout during branched development is a best practice. By checking out rules, developers avoid situations in which two or more team members edit the same rule. Rule checkout also creates a rule history, which developers can use to analyze changes in the rule, or to revert the rule to a specific state.

Branched development supports continuous integration and continuous delivery (CI/CD) pipelines, so that developers deliver well-tested software through an agile and iterative development process. For more information about CI/CD pipelines, see Understanding continuous integration and Understanding continuous delivery.

Application development for a single developer and small-scale teams

When only one person works on an application, or the project involves a small and communicative team of up to four or five members, branched development and rule checkout are not required, because the implemented changes do not affect other developers. For a small development team, communicating the changes that the developers intend to implement is crucial to avoid work overwrites and errors. This business scenario is untypical and usually applies in situations when a developer builds an application for learning purposes, or creates an application as a citizen developer. Typically, citizen developers have limited technical background and focus on more granular applications. Similar scenarios include the very early stages of application development process, when a client and a software company define requirements for a new application.

Working in unlocked rulesets is a good approach for development projects that include very limited CI/CD pipelines. As a best practice, if you intent to move an application to a production environment, implement branched development first.