High-velocity DevOps teams rely on version control management to safely and effectively collaborate across products, projects, and teams. With branching and version control in mabl, team members can make isolated changes to tests and flows without impacting the core testing suite or interfering with each other's work. Just as importantly, members can easily and safely integrate their changes back into the core testing suite when ready without interrupting the CI/CD pipeline for software development.

Branching use cases

When it comes to branching tests, there are three main use cases:

• Make isolated changes to a test without affecting the master version of that test. For example, you may want to implement additional steps, but you want to develop and test those steps safely without disrupting test runs that are in production and monitored by the rest of the team.
• Run different versions of the same test across different environments (e.g. dev and prod) or different versions of the same application under test. For example, your team may want to run the master version of a test against production and a branched version that incorporates the latest changes against staging. Similarly, a developer may want to run their own version of a test against a preview environment where they are doing their active development.
• Promote mabl tests together with code across CI/CD environments. For example, as a developer builds a new feature on a branch in their application source code (e.g., in GitHub), they can create an associated branch in mabl to add new tests or update existing tests to cover the changes. When the feature branch is ready to be merged to their staging environment (where a regression suite may be triggered by the deployment), they can merge their mabl branch at the same time to synchronize the changes and run the updated tests against the updated application.

How branching works in mabl

Every workspace in mabl starts with a master branch which represents the primary line of development. When you make changes and save a test or flow, a new version is created and stored on the master branch. Whenever a test is run, mabl executes the latest version of the tests and flows.

You can create development branches which represent a separate line of development that diverges from the master branch. Newly created development branches do not automatically put all the tests and flows onto the branch. A test or flow is added explicitly to the branch once a new change has been saved to an existing test or flow, or by creating a new test or flow on the branch directly. When merging a development branch into master, you can resolve step and variable conflicts ahead of time to avoid unintentionally overwriting changes on master.

When you run a test on a branch, mabl executes the latest version of the test or flow on that branch. If a test or flow is not on the branch, the latest version of the test or flow on the master branch is executed.

🚧

Branching limitations

• Only branching from master is supported (i.e. you can’t pull versions from development branch A to development branch B or resolve conflicts between two development branches)
• You cannot view a test or flow's revision history by branch; the versions represent saved versions of a test or flow in sequence from either the master branch or the development branch.
• There is no support for branching snippets; updating a snippet on a development branch will update that snippet across all development branches and versions where that snippet is used.
• There is no support for branching visual tests.
• API tests can be branched, however viewing the differences is not supported.
• Once a branch is merged, it cannot be reopened and you can’t run tests against merged branches.
• You cannot revert an entire branch. This means there is no way to revert to the previous versions of all tests or flows on a branch at one time; however you can do this individually by test or flow.
• Test or flow metadata such as name, description and labels are not version controlled.

To get started with branching in your workspace, take a look at the following guides:

• Creating branches
• Running tests on branches
• Managing branches

Snapshots

Snapshots apply to an entire environment and freeze the state of your tests and flows at a certain point in time. This is useful if you want to preserve the state of tests running against an application in one environment (the snapshot environment) while making active updates to the same tests running in another environment.

For more information on using snapshots, check out the guide.