Skip to main content

Branch Flow

There are two branch flows recommended when testing using Testspace:

  • Main flow
  • Release flow

Main flow#

The Main flow is based on the GitHub flow. The main branch, set as the default, is used for testing releases, with branches created off the main for working on new test development.

github.com/org/repo/branches
โ””โ”€ main
โ””โ”€ testdev/abc_tests
โ””โ”€ testdev/def_tests
..

Releases#

The Main flow is based on continuously testing the main branch, which is assumed to always being in a deployable state (or at least ready for system testing).

Tip: Update the main space description to reflect the name of the major release.

When a release has been completed/deployed it is recommended to tag the repo and pin the results adding a link to the commit id representing the repo being tested.

Pin Release Results

Tip: Follow the same release naming of the repo being tested.

Hotfix#

If a hotfix patch is required to be tested a release branch can be deployed based on a tag.

$ git checkout -b release_42.4.1 tags/v42.4
..
$ git push origin release_42.4.1

Hotfix branch

Release flow#

The Release flow is loosely based on the Gitflow, where a release branch represents the testing for a specific release of the system under test. This flow is especially useful when multiple releases are required to be maintained at the same time.

The Release flow is especially useful when multiple releases are required to be tested separately.

A common practice is to name the branch based on the system under test release name.

github.com/org/repo/branches
โ””โ”€ main
โ””โ”€ release_abc
โ””โ”€ release_def
..
โ””โ”€ testdev/def_tests
..

Branches are used for testing releases of the system under test.

Carry Results#

When branching, if the base branch has test results, the results will be copied as a new baseline for the space corresponding to the newly created branch. The baseline suites will be carried forward on subsequent test sessions.

To assure proper baseline result carrying make sure to create your new branch out of the appropriate base branch with results. For example:

git checkout release_abc
git checkout -b release_def
..
git push origin release_def

The new branch (i.e. release_def) will reference the current release_abc results as it's baseline.

New Branch

In the next session, all tests not executed will be carried from the baseline (release_abc result at the time of branching).

New Branch Results

Once a branch is deleted within GitHub the corresponding space containing results will also be deleted.

Don't delete branches with test results you want to keep. A branch deletion results in the corresponding space being deleted.

Note that if the base branch has no test results, no previous results will be carried into the newly created branch. For example, creating a branch using a base branch that has no .testspace.yml file will establish a new empty baseline.

Test Development#

Test development should be done using a separate/isolated process following good development practices. When developing new tests a sandbox space should be used. More specifically create a "feature" branch off the main branch (or latest release branch) and use a pull request for review by your peers before merging back into the base branch.

Once a pull request is open you can discuss and review changes with your peers.

$ git checkout main
$ git checkout -b feature/abc_test
..
$ git push origin feature/abc_test

Tip: Consider adding a Testspace session link in your pull request to aid in the review.