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.
This is a list of important things Tramline currently automatically does with little to no user intervention.
Cutting a release branch
On starting a new release, we automatically cut a release branch from the specified working branch for the repo.
This is always in the form of
For example, if your release train is called Nightly, the release branch will be
r/nightly/2023-06-02. Additional releases during the day will be
The release will listen to commits on this branch after it has been created.
Cutting a release tag at the end of a release
Once the release is finalized, we automatically tag the last commit that was released with the version generated by the release train. If the released version is
1.0.0. The tag will be
If you're using the GitHub integration for source control, we will also create a GitHub release with an auto-generated changelog.
Creating and merging pull requests
We wholly manage pull requests around release branches while starting and ending a release (depending on the branching strategy selected).
See Branching Strategy for more information.
Managing version names and build numbers
Every app that is added to Tramline maintains an atomic counter for the build number. Regardless of what trains are running for the app, every workflow run will internally and externally update the build number for the generated build.
This ensures that every build generated by Tramline across configured workflows always have a unique value.
Version names are processed in a
major.minor.patch format, where the
patch term is optional.
✅ Allowed versions:
❌ Invalid versions:
Every new release increments the
Once your release has reached a store (App Store or Play Store) production channel and has been distributed to at least some percentage of users (via staged rollout), any new commit on the release branch increments the
patch version. When that happens, your release enters a
A release in
hotfix mode simply means that you are pushing changes on the build that has reached some of your user-base and has a bug that warrants immediate fix rather than a new release altogether.
1.0.0 --> 1.1.0
New commits after production distribution has begun
1.1.0 --> 1.1.1
This mechanism is implemented with the assistance of a small CI snippet described here.
Triggering step workflows on commits
When you start a release or when you land commits on a release branch; we automatically run the steps and their workflows and send the builds generated from the workflows to the correct build channels.
This ensures that all the users and stakeholders of all the relevant build channels are kept up-to-date on new changes without requiring manually sharing builds around. This is especially handy when the app is being QA'd (internally or externally) via the review steps.