Ongoing Release
When you start a new release, this page is your control panel. Everything about the current release is controlled from right here. You will likely spend most of your time in Tramline here.
This is what a typical successful release in Tramline looks like:
Run the first step of the train automatically
There are a few things Tramline does as soon as the release starts:
- It creates a release branch off of your working branch.
- It starts the first step in your release train and triggers the CI workflow for that step.
- Once the CI workflow is finished, Tramline will distribute the build generated by the workflow to the configured distribution channels.
Subsequent steps (review or release) of the train are run in order with a manual trigger after the first one finishes.
A release step is also auto-triggered if your train has only one step.
New commits landing will re-trigger steps
It's common to add bug fixes and sometimes even small new features to a release after the release branch has been created.
When a new commit lands on the release branch of your app, Tramline will restart the release train from step one with the latest commit on the release branch.
If you're on step number 2 of a 3-step train, landing a new commit to the release branch will re-trigger step 1 & 2 automatically. This is so that the stakeholders of those steps are informed of the updates made to the release.
Since release steps may have production deployments, Tramline plays it safe and does not auto-trigger this step for subsequent commits.
Remember, Tramline always works on the latest commit or the HEAD of the release branch.
All commits
The All commits section of the page will show all the commits that land on the release branch. You can refer to the state of the release train at each of the commit.
You can also see the corresponding CI workflow and build details for each commit in this section of the page.
Release metadata
You can update release-related metadata prior to initiating your production store release. These details can be modified anytime between the beginning of the release and the commencement of a production deployment, as the metadata will be uploaded to the store during the production deployment process.
- Release notes
- Promotional text (iOS only)
Tramline will add some sensible defaults for these for your benefit.
Controlling the production release
The production release across both stores in handled by Tramline slightly differently due to the different processes of these stores.
iOS
If your release step has a production channel, you are presented with:
When you start the release step, Tramline automatically creates an inflight release on the App Store and assigns the correct build to the that release. Once the release is prepared, you have to submit the app for review.
Once you have submitted the app for review, you can track its progress on the right:
This widget above will always show the latest status of of the release on TestFlight or App Store.
Once the review is approved by Apple, you can start the release of the build from Tramline.
If there is no phased release enabled, your release is complete! 🎉
Phased release
If you have production release with a phased release, you will be presented with controls to start the phased release.
Once the rollout is started, you can pause (and resume) the rollout, halt it, or, release to all the users right away if you confident about your release.
Android
If your release step has a production channel, you are presented with:
When you start, Tramline creates a release in Play Store. It also automatically promotes the release on the production track.
If there is no staged rollout enabled, your release is complete! 🎉
Staged rollout
If you have a production release with staged rollout, you will be presented with controls to navigate your staged rollout.
Once the rollout is started, you can increase the rollout, halt it, or, release to all the users right away if you confident about your release.
Finishing up
Once the build has been successfully distributed to all channels in the release step, you can finalize your release.
This would typically tag the correct release commit, and depending on the branching strategy, it will also automatically create and merge necessary pull requests.
Once a release is finalized, it becomes locked and is unable to accept any further patches or commits.
