Skip to main content

🤖 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.

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 r/name-of-release-train/date-of-release.

For example, if your release train is called Nightly, the release branch will be r/nightly/2024-04-19. Additional releases during the day will be r/nightly/2024-04-19-1.

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 v1.0.0.

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 Strategies for more information.

Managing version names and build numbers​

Build number​

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 Name​

Version names are processed in a major.minor.patch format, where the patch term is optional.

✅ Allowed versions:

1.2.0
4.2.1
16.9

❌ Invalid versions:

1
1.2.3.4

Every new release increments the minor version.

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 hotfix mode.

Hotfix​

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.

New release​

1.0.0 --> 1.1.0

New commits after production distribution has begun​

1.1.0 --> 1.1.1

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.