Branching strategies

Release branching strategies supported by Runway
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 reach out for guidance on configuring Runway to accommodate your team's branching strategy.
Version-specific release branches
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.
Some examples of version-specific release branch names: release-1.1.0, v1.1.0 and release-major-2.0.0.
Runway expects version strings that adhere to Semantic Versioning 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 Integrations settings.
Enter your release branch pattern as a tokenized string under Release branch
Define your main working branch under Additional branches
Runway has available automations that will merge the release branch back into the working branch (and any existing open release branches), and delete version-specific release branches at the end of the release cycle.
Static release 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.
An example of a static release branch strategy is having a persistent working branch named main, paired with a persistent release branch named production.
You can configure Runway for a static release branch workflow from Integrations settings.
Enter your release branch name as a string under Release branch
Define your main working branch under Additional branches
Three-flow
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.)
An example of a three-flow strategy is a working branch named main, a staging branch named staging and a release branch named production.
You can configure Runway for a three-flow branching strategy from Integrations settings.
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.
Trunk-based, release from trunk
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.
An example of a trunk-based branching strategy that releases from trunk is having a single, persistent branch named main, with no release branches created.
You can configure Runway for a trunk-based, release from trunk strategy from Integrations settings.
Enter your main branch name under Release branch 
Enter the same branch name into the Working branch field found under the Additional branches 
Getting started - Previous
Setting up your integrations
Builds and branches
Last modified 7mo ago