🤖 Automations
Tramline automates away a lot of boilerplate work and opines on some sensible defaults. We will continue to add more automations and hopefully also add controls to chose which ones to run. Currently, some sensible automations (that everyone should do) are just magically done for you, and some require enabling manually.
If you have suggestions for common processes that Tramline can automate for you, which don't exist in this list down below, please let us know!
Cut a release branch
This automation is run when a new release is prepared.
Release branches are only cut for specific branching strategies. See Branching Strategies.
On starting a new release, we automatically cut a release branch from the configured working branch for the repo. The release branch takes the pattern of r/name-of-release-train/date-of-release. For example, if your release train is called Nightly, the release branch will be r/nightly/2026-02-10. Additional releases during the day will be r/nightly/2026-02-10-1.
Pre-release pull requests
This automation is run when a new release is prepared.
Only works for Parallel Working and Release Branch strategy.
The working branch (eg. main) is merged into the static release branch (eg. release) automatically at the the start of every release.
Start release flow for new commits
This automation is run when new commits land on the release branch.
When you land fixes to your release branch for an active release, the Tramline release flow automatically kicks off again. If you have Internal Releases enabled, on the arrival of every new commit, a new internal release process will start. If you only have Release Candidates enabled, only the release candidate process will automatically start. When any of this happens, the previous internal or RC builds are marked as stale, so that you can start working on the fresh builds.
Trigger workflows
This automation is run when new commits land on the release branch.
When an internal or release candidate process starts, the associated workflow is automatically triggered. The subsequent updates to that workflow are also tracked and updated in the dashboard.
Trigger distributions
Enable this in your submission settings.
When a workflow finishes and a build is found, Tramline can optionally auto-submit the build to the configured distribution channel.
Auto-start rollout after submission
Enable this in your production release settings.
When enabled, Tramline automatically starts the production rollout as soon as the submission is approved (iOS) or prepared (Android), removing the need for a manual trigger. Pre-production releases always auto-start regardless of this setting.
Automatic rollout
Enable this in your production release settings.
When enabled for Android, Tramline automatically progresses the staged rollout percentage once daily according to the configured sequence, as long as the release is healthy. The rollout is automatically paused if health rules detect problems. On iOS, automatic rollouts are enabled by default for all phased releases.
Unblock upcoming releases
See Suspending Releases for details.
In synchronized releases, locking a platform automatically unblocks upcoming releases for that platform, allowing them to proceed to production independently. This avoids one platform holding up the entire release pipeline.
Cancel previous workflow run
When a new commit lands, and if there's already a workflow running for a previous commit, Tramline will attempt to cancel the previous workflow run. We do this to avoid wasting compute minutes.
Apply change queue
Enable build queues in your release train settings.
Changes that land on the release branch can optionally be staged in a Change Queue. The change queue gets automatically drained if either the number of changes in the queue exceed the configured limit or if the configured batch-time has passed.
Track ongoing work
This automation is always available as long as the release is active. See changeset tracking.
All the pull requests that directly target the release branch (eg. r/production/2022-12-31-1) are automatically tracked and updated in the changeset tracking dashboard.
Bumping versions and build numbers
Versions
Versions are automatically managed by Tramline. New releases start with a minor or major version bump (in SemVer terminology). When fixes land in the middle of a production rollout, the patch version always gets auto-bumped for the new changes.
Similarly, when starting new hotfix releases, the patch version always get auto-bumped.
Build numbers
Every build created generated through Tramline always has a unique build number. This is true across workflows, and across trains. Tramline maintains an atomic counter internally and automatically updates the build number through the workflow triggering mechanism.
Merging fixes back
This is applicable for all branching strategies.
Tramline will always automatically try to merge (not just create) all PRs that are created by Tramline, whenever possible (depending on required checks etc.).
Tramline can automatically backmerge changes from the release branch to your working branch and any upcoming release branches. There are two backmerge strategy options available.
Continuously as changes land
Any PRs or commits merged into the release branch will be "backmerged" into the working branch. As new changes land, this process repeats so that the working branch is always up to date with the release branch. This is helpful for teams that do a number of fixes directly on the release branch so that the code is merged back to the "trunk" as quickly as possible.
Depending on the VCS integration, the way cherry-picks happen have will slight variations.
These running PRs created by Tramline are sometimes referred to as Patch PRs. These PRs get also get assigned to the original authors of the relevant change/commit.
End of release
A backmerge branch will only be created if commits are found on the release branch that are not on the working branch.
At the end of the release cycle, Tramline will create a backmerge branch and open a pull request to merge the release branch back into the working branch and also to any upcoming release branch.
Notifications
Enable Notifications in your release train settings.
Attach builds
Along with all the available notifications, the "build available" notification specifically attaches the Internal or Release Candidate build as a part of the Slack notification. This is helpful for QAs or other folks in the configured Slack channel to quickly download the build for testing.
Tester notes
When a new build is available to download from Tramline, in addition to the build itself, Tramline also sends the list of changes that were made for the build (since the last build) in the Slack notification. This tells anyone who is downloading the build what changes were made in it. The same information is also available in the Tramline dashboard.
Create VCS tags
Enable tagging in your release train settings.
Tramline cuts git tags on your version control in a couple of different scenarios:
End of a release
When the release ends, we automatically tag the last commit that was released at the end. If the released version is 1.0.0. The tag will be v1.0.0.
When a production submission finishes
For cases where you anticipate sending more than one build to the store, we also allow tagging each submission that actually went to the store. So in a single release, if you first partially release 1.0.0 to the production track on Play Store, and then land a patch fix and release 1.0.1 to 100%, you will get two tags: v1.0.0 and v1.0.1 against the appropriate commits.
Create VCS release
VCS releases are created at the end of a release.
If you're using the GitHub integration for version control, Tramline will automatically create a GitHub release with an auto-generated changelog.
Pick the correct version for hotfixes
When you start a hotfix release, Tramline will automatically pick the correct version to be hotfix'd (the last completed release). When the hotfix release starts, and if there's a diff — between the current hotfix changes and the last release — the release will jump straight into to creating a new Release Candidate build and will skip Internal builds to save time.
Start releases on a schedule
Add a schedule to your release in the release train settings.
Scheduled releases automatically start a new release on the specified date and retain the schedule for subsequent releases. You can also optionally set a scheduled release to automatically stop on failure.
Additionally, if your release spans across a future release, the future release gets automatically adjusted.
Update Export Compliance Information in App Store Connect
If enabled, Tramline will automatically sets the usesNonExemptEncryption to be false for all builds as they get upload to the App Store.
Upload builds to Tramline
By default, all builds generated by your CI workflows as artifacts are automatically uploaded to Tramline. This is true for the following file types: aab, apk and ipa. They are subsequently also available for download from the Tramline dashboard and Slack notifications.
Default release notes from last release
Tramline will automatically apply "What's new" text or release notes from your previous release version to populate the release notes for the current release.
Additionally, if you manually add new locales for your release notes directly on the stores, Tramline will automatically pull them up in the next release.
Pull Requests
Pull requests are created under a variety of circumstances (see above).
There are a few default automatic settings for all pull requests created by Tramline:
- If the PR is on the GitHub VCS integration, Tramline will try to set the auto-merge option (if possible).
- Even if auto-merge flag is not possible (eg. other VCS integrations), Tramline will continually try to auto-merge until all the checks pass.
- For cherry-pick PRs (or "patch" PRs), Tramline will reference-tag the name of the author of the cherry-pick commit in the body of the PR.