Branching strategies
Release branching strategies supported by Runway
Last updated
Was this helpful?
Release branching strategies supported by Runway
Last updated
Was this helpful?
Runway supports a variety of the most common release branching strategies, covering the majority of teams we've encountered to date. Below, you'll find helpful guides on how to configure Runway for each.
If your team uses a setup that's not described here, feel free to for guidance on configuring Runway to accommodate your team's branching strategy.
With the version-specific release branch strategy, day-to-day development happens on a single, long-lived working branch. When the time comes to prepare for a new release, a new release branch is created which includes the version in the branch name.
Runway expects version strings that adhere to principles — formatted as x.y.z (representing major.minor.patch).
A release candidate build is created from the code on this release branch (usually on every merge or push into the branch), and testing begins on the release candidate build. If issues are discovered, fixes are merged into both the working branch and into the release branch.
Creating a version-specific release branch allows normal day-to-day development to continue on the working branch, while production-ready code is kept isolated on the release branch as it goes through regression testing.
You can configure Runway for a version-specific release branching workflow from .
Enter your release branch pattern as a tokenized string under Release branch
Define your main working branch under Additional branches
With the static release branch strategy, day-to-day development happens on a single, long-lived working branch, while a single, long-lived release branch exists in parallel with the main working branch. When preparing a new release, production-ready code is promoted from the working branch to the release branch, which triggers the creation of a release candidate build.
You can configure Runway for a static release branch workflow from .
Enter your release branch name as a string under Release branch
Define your main working branch under Additional branches
In the three-flow branching strategy, teams maintain three long-lived branches: the main working branch, a staging branch, and a production branch. When preparing for a release, code is promoted from the working branch to the staging branch, and finally to the production branch.
The staging branch will trigger the creation of release candidate builds which are distributed for testing. The final build that is submitted to the app store is generated off the production branch. (In some cases, the staging branch builds will have a different bundle ID or package name than the final production build.)
Enter your staging branch name under Release branch
Define your main working branch under Additional branches
Enter your final deploy branch name under the Deploy branch field found in Additional branches
Runway defines the Release branch as the branch that generates the release candidate builds which are used for regression testing. For this reason, when using the three-flow strategy, the staging branch should be considered the release branch when configuring branches in Runway.
A trunk-based branching strategy that also releases from trunk is defined by a single, long-lived branch that's used for both development and deployment. Rather than creating branches to kick off release candidate builds, CI/CD workflows are often triggered manually or by creating tags.
Enter your main branch name under Release branch
Enter the same branch name into the Working branch field found under the Additional branches
You can configure Runway for a three-flow branching strategy from .
You can configure Runway for a trunk-based, release from trunk strategy from .