{ "version": "https://jsonfeed.org/version/1", "title": "Tramline Changelog", "home_page_url": "https://docs.tramline.app/changelog", "description": "Keep yourself up-to-date about new features in every release", "items": [ { "id": "https://docs.tramline.app/changelog/january-30-2026", "content_html": "

\n

Smart staged rollouts​

\n

Tramline can now automatically progress your Android staged rollout. When enabled, the rollout advances to the next configured stage once every 24 hours, as long as the release remains healthy. If release health rules detect problems, the rollout is automatically paused. You can manually pause, resume, or switch back to manual control at any time.

\n

Read more about configuring automatic rollouts → here

\n

Auto-start rollouts after submission​

\n

Production rollouts can now start automatically without manual intervention. On iOS, enabling this sets the release type to \"After Approval\" in App Store Connect — once Apple approves the review, the release begins on its own. On Android, the rollout kicks off as soon as submission preparation completes.

\n

Read more about auto-start rollouts → here

\n

Form-factor support (Android only)​

\n

\n \n

\n

You can now target Android releases to specific device form factors — Wear OS, Android TV, Automotive, and Android XR. These can be configured both on production and internal submissions.

\n

\n \n

\n

Note that we currently don't support a hybrid release of separate form-factor tracks to production from the same release train. We recommend creating separate trains or apps for this. Separate tracks for Internal/Beta submissions are, however, supported in a hybrid way.

\n

Auto-update inflight release with latest RC​

\n

When a new release candidate build is generated while a production release is still awaiting review, Tramline now automatically swaps in the latest build and re-prepares the submission. This keeps your in-flight release current without manual intervention.

\n

Lock platforms​

\n

For synchronized releases, you can now lock individual platforms to mark them as complete independently. This unblocks upcoming releases for that platform without waiting for the other platform to finish. Critical fixes can still be applied after locking.

\n

\n

Read more about locking platforms → here

\n

Draft release notes​

\n

Release notes and other text metadata (like iOS promo text) that don't meet store validation requirements are now saved as a draft. You can re-apply, edit, and save them as needed.

\n

\n
Improvements and Fixes
\n\n
    \n
  • Don't create version bump PRs for hotfix releases
    • \n
  • Make scheduled releases DST-insensitive (rely on time-of-day)
    • \n
  • Review-rejected builds can now be resubmitted
    • \n
  • Limit production blocking checks to active releases only
    • \n
  • If git tagging fails, do not block further operations
    • \n
\n
", "url": "https://docs.tramline.app/changelog/january-30-2026", "title": "January 30, 2026", "summary": "Smart staged rollouts", "date_modified": "2026-01-30T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/december-17-2025", "content_html": "

\n

Time-limited soak period​

\n

Soak is a designated way to block releases from moving to production until a configured time period has passed. Soak starts as soon as the first RC is available and allows time to monitor the RC before proceeding to send the app to production tracks. Soak can be configured under your Release Settings, in increments of 1 hour. It is available for all apps: android, iOS and cross-platform.

\n

The Release Candidate step will show a pending status as long as the soak is running. You can optionally end early or extend the configured soak period. All soak related actions come with with individual notifications that can be turned on/off.

\n

Improvements to preparing new releases​

\n

Release from commit SHA: if you're not not sure if the working branch is stable to deploy, you can choose a specific commit from an older point in history and cut the release branch from there.

\n

\n \n

\n

Start release from mobile view: a quick quality-of-life improvement to the mobile-browser view that allows you to start releases as you normally would (with all standard options).

\n

\n \n

\n

GitLab re-authorization​

\n

GitLab as an integration is notoriously flaky in terms of liveliness. The access tokens tend to expire too quickly and the TTLs aren't particularly well-documented. If one doesn't touch Tramline for a while, this integration can get disconnected in the background. Tramline now handles this gracefully and prompts you to re-authorize GitLab (CI/CD or VCS both).

\n

\n \n

\n
Improvements and Fixes
\n\n
    \n
  • Fix release schedules to strictly adhere to time-of-day and not be DST-sensitive
    • \n
  • Fixed concurrency bug with multiple invites being sent out to users
    • \n
  • Better auth checks around role escalation (previously only on client-side)
    • \n
  • Fix the refresh button when Tramline is finalizing a release
    • \n
\n
", "url": "https://docs.tramline.app/changelog/december-17-2025", "title": "December 17, 2025", "summary": "Time-limited soak period", "date_modified": "2025-12-17T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/december-1-2025", "content_html": "

\n

Edit release settings​

\n

Previously, Tramline blocked editing release settings while an active release was running — a sensible safeguard at the time. This restriction has now been relaxed: you can tweak your release train settings even during an ongoing release, and the changes will apply starting with the next one.

\n

The only exception is versioning and branching strategies. These remain set-once. If you need to change them, you can create a new train and retire the current one.

\n

This update now also allows you to tweak your release schedule (which was previously not possible).

\n
note

Submission settings are always editable regardless of the state of your release.

\n

App Icons​

\n

\n

In app settings, you can now upload a size-compatible app icon to help visually distinguish your apps when you have multiple configured in Tramline. You can add an icon anytime, either when creating a new app or after setup.

\n

Disable all back-merges​

\n

Until now, Tramline let you choose between creating a single final back-merge PR at the end of a release cycle (the default) or continuously creating PRs for commits landing in the release branch.

\n

For teams following trunk-based development, back-merges often aren’t useful. You’re typically cherry-picking all commits (including fixes) from trunk into the release branch.

\n

If you follow a TBD workflow, you can now disable back-merges entirely.

\n

\n
Improvements and Fixes
\n\n
    \n
  • Upcoming releases can be started even if the previous release is partially rolled out to Production (only one store in a cross-platform release)
    • \n
  • If a review fails on iOS, you can now re-submit from Tramline without needing to land another commit to kick-start another cycle
    • \n
  • Integrations are now configured per integration, instead of per category
    • \n
\n
", "url": "https://docs.tramline.app/changelog/december-1-2025", "title": "December 1, 2025", "summary": "Edit release settings", "date_modified": "2025-12-01T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/september-4-2025", "content_html": "

\n

Outgoing Webhooks​

\n

Tramline's outgoing webhooks notify you in real-time when certain events happen in your release. Webhooks are HTTPS POST requests made to an endpoint of your choice that you can then implement custom business logic for. For example, you can receive a webhook when the release first kicks off. Your endpoint that receives this webhook can then process the payload of the webhook to automate some internal process you have based on this event, such as triggering a different pipeline, creating a ticket, or sending a custom notification or email to your team.

\n

We currently support the following events:

\n\n

Read more about configuring webhooks → here.

\n

Custom content in Slack notifications​

\n

\n \"Slack\n

\n

Teams can now add custom user-defined content to their Slack notifications, providing additional context and personalized information alongside standard release updates. This enhancement allows release managers to include:

\n\n

\n \"Slack\n

\n

The custom content appears as a separate section in Slack notifications and can be configured per notification type.

\n

Read more about configuring custom notification content → here.

\n

Flexible release branch names​

\n

Release branch naming is now fully customizable with dynamic token substitution. Teams can create branch naming patterns that automatically include contextual information like train names, release dates, and version numbers.

\n

Available tokens include:

\n\n

For example, a pattern like release/~trainName~/~releaseVersion~/~releaseStartDate~ would generate branch names like release/production/1.2.0/2025-08-29.

\n

Read more about how tokens in patterns work → here

\n
Improvements and Fixes
\n\n
    \n
  • Enhanced error reporting when App Store rollouts fail to start
    • \n
  • Added automatic retries for release branch creation to improve reliability
    • \n
  • Retries for workflow triggers to handle transient failures for GitLab Pipelines
    • \n
  • Link to Release Activity page on Rollout timeline panel
    • \n
\n
", "url": "https://docs.tramline.app/changelog/september-4-2025", "title": "September 4, 2025", "summary": "Outgoing Webhooks", "date_modified": "2025-09-04T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/september-2-2025", "content_html": "

\n \n

\n

Limited Mobile experience​

\n

Tramline now includes dedicated mobile views, making it easier for teams to monitor and manage releases on mobile devices. The mobile experience includes:

\n

Release List View: Browse all releases with a mobile-optimized layout

\n

Release Details: View release summaries with essential information

\n

Production Rollout Controls: Manage rollout percentages and status directly from mobile

\n

This mobile support is particularly valuable for release managers who need to monitor or respond to release issues while away from their desktop. We will continue to add more desktop-like controls to this view in the future. Feel free to reach out if you have any suggestions!

\n

Cleaner changelogs in notifications​

\n

Changelogs sent in notifications are now much cleaner and more focused, with automatic filtering to remove noise from pull requests and irrelevant commits. This enhancement improves the readability of release notes by:

\n\n

The result is more scannable logs that focus on the meaningful changes shipped in each release, making it easier for teams and stakeholders to understand what's new.

\n
Improvements and Fixes
\n\n
    \n
  • Enhanced search functionality with improved filtering and results display
    • \n
  • Improved GitLab repository fetching to include all accessible repositories
    • \n
  • Fixed navigation issues when using the back button from Account Settings
    • \n
\n
", "url": "https://docs.tramline.app/changelog/september-2-2025", "title": "September 2, 2025", "summary": "Limited Mobile experience", "date_modified": "2025-09-02T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/august-28-2025", "content_html": "

\n

Bitrise Pipeline support​

\n

Bitrise users can now also use pipelines with Tramline. This enhancement provides more flexible workflow management beyond the standard Bitrise workflow configurations.

\n

Pipelines allow teams to:

\n\n

Flexible Build Number management​

\n

Teams now have full control over how build numbers are managed in their release process. Tramline supports two distinct strategies:

\n

Internal Management (existing): Tramline automatically increments build numbers for each release, maintaining consistency across your release train.

\n

External Management (newly added): Build numbers are expected to be the CI workflow numbers (typically monotonically increasing)

\n

\n

This flexibility is particularly useful for teams with complex versioning requirements or those who prefer to manage build numbers within their existing CI/CD infrastructure.

\n

Resilient Build discovery​

\n

Tramline now Automatically finds builds that were uploaded directly to app stores by CI workflows. This improvement makes the release process more robust when dealing with:

\n\n

The system will automatically retry and attempt to locate builds in the target stores, ensuring your release process continues smoothly even when build attachment fails initially.

\n
Improvements and Fixes
\n\n
    \n
  • Improved Firebase build discovery logic during preprocessing phase
    • \n
  • Reduced retry attempts for attaching build artifacts
    • \n
  • Fixed Bitrise integration connection checks to only validate connected integrations
    • \n
  • Better error handling for GitHub parameters that aren't accepted by target workflows
    • \n
\n
", "url": "https://docs.tramline.app/changelog/august-28-2025", "title": "August 28, 2025", "summary": "Bitrise Pipeline support", "date_modified": "2025-08-28T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/august-26-2025", "content_html": "

\n

Linked Tickets and PRs in changelog notifications​

\n

Changelogs now automatically detect and create clickable links for project management tickets/issues and pull requests mentioned in commit messages sent over Slack. This enhancement makes it much easier to navigate from release notes to the underlying work items and code changes. Supported integrations include:

\n

Version Control: GitHub, GitLab, Bitbucket pull requests

\n

Project Management: Jira tickets, Linear issues

\n

The feature automatically detects patterns like PROJ-123 for tickets or #456 for pull requests and converts them into clickable links that open directly in the respective tools. This can be enabled or disabled per release train based on team preferences.

\n

New Release notifications​

\n

\n

Both these new notifications have dual-set changelogs that are threaded (after 20 items) into multiple messages.

\n

Production Rollout Started Notifications: When a production rollout starts, the changelogs for this release and another set for the current rollout changes (if there are multiple rollouts) are threaded into the notification.

\n

RC Finished Notifications: When any RC build is generated and sent to appropriate submissions. Changes since the last RC build and all the changes since the release started are threaded in as well.

\n

Both notifications have linked tickets (Project Management integration should be enabled) and PRs in their changelogs.

\n

Version Bumping strategies​

\n

Teams now have more granular control over version bumping with new strategic options for different release scenarios:

\n

In Current Version Before Release Branch Cuts, Tramline will increment the version information in your code before cutting the release branch for a new release.

\n

In Next Version After Release Branch Cuts, Tramline will increment the version information in your code after a release branch has been cut and the release has started.

\n

Learn more about version bumping strategies → here.

\n

\n
Improvements and Fixes
\n\n
    \n
  • Added Play Store deep links to RC finished notifications for easier access
    • \n
  • Improved right-side pane behavior to close when clicking outside
    • \n
  • Updated documentation links throughout the application
    • \n
  • Ensured version bump jobs only run for appropriate release strategies
    • \n
\n
", "url": "https://docs.tramline.app/changelog/august-26-2025", "title": "August 26, 2025", "summary": "Linked Tickets and PRs in changelog notifications", "date_modified": "2025-08-26T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/august-21-2025", "content_html": "

\n

Linear and Jira integrations for Project Management​

\n

Tramline now supports Linear as a project management integration in addition to Jira, expanding the platform's ability to connect with project management tools. This integration provides the foundation for tracking project tickets and linking them to releases.

\n

The project management integrations currently allow for configuration of workspace, issue statuses and release labels (or fix versions).

\n

\n

While this initial implementation focuses on connection and configuration, future updates will expand Linear and Jira support to include automatic issue tracking and linking within releases.

\n

Enhanced GitLab support​

\n

GitLab integration has been significantly improved with added support for GitLab CI/CD and making the VCS integration up to date with the updated features. Key improvements include:

\n

GitLab Pipelines Support: Full integration with GitLab's CI/CD pipeline system

\n

Artifact Processing: Improved artifact downloading and filtering with optional pattern matching

\n

Better Error Handling: More granular error reporting for workflow triggers and pipeline failures

\n

Cherry-pick PRs: Ability to cherry-pick commits from the release branch to the working branch

\n

This brings GitLab integration to feature parity with other supported CI/CD platforms like GitHub Actions and Bitrise.

\n

Learn more about setting up GitLab integrations → here.

\n
Improvements and Fixes
\n\n
    \n
  • Improved workflow trigger failure handling across all CI/CD integrations
    • \n
  • Added build number display to \"Previous Releases\" section for better version tracking
    • \n
  • Fixed YAML formatting issue in invitation email templates
    • \n
  • Improved Slack message formatting for publishing review notifications
    • \n
\n
", "url": "https://docs.tramline.app/changelog/august-21-2025", "title": "August 21, 2025", "summary": "Linear and Jira integrations for Project Management", "date_modified": "2025-08-21T00:00:00.000Z", "author": { "name": "Animesh Ghosh", "url": "https://github.com/Animesh-Ghosh" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/august-19-2025", "content_html": "

\n

Release-Specific notification channels​

\n

Teams can now create dedicated Slack channels for individual releases, providing focused communication spaces for each release cycle. Key features include:

\n

Creation: Channel is created with sanitized names including app, platform, and version

\n

Context: Each channel is specific to a single release, reducing noise and improving focus

\n

Configuration: Can be enabled per release train based on team preferences

\n

This feature is particularly valuable for teams managing multiple concurrent releases or those who prefer dedicated communication channels for major releases.

\n

Advanced Tagging scenarios​

\n

Tramline now supports much more flexible tagging strategies to accommodate different team workflows and release processes. Teams can configure exactly when and how tags are created throughout their release lifecycle:

\n

End-of-Release Tagging: Cut tags only when releases complete (with optional GitHub release)

\n

Rollout-Based Tagging: Cut tags when rollouts start (with optional GitHub release)

\n

Platform-Specific Tags: Include platform suffixes for cross-platform apps (like -ios or -android)

\n

\n

These options give teams fine-grained control over their tagging strategy, supporting everything from simple end-of-release tags to complex multi-platform, multi-rollout scenarios.

\n
Improvements and Fixes
\n\n
    \n
  • Enhanced Bitbucket workflow stage halting capabilities
    • \n
  • Added support for APK uploads to Play Store with feature flag control
    • \n
  • Improved artifact attachment reliability across all platforms
    • \n
  • Fixed integration connection checks to properly ignore disconnected integrations
    • \n
  • Added confirmation dialog before refreshing Slack channels
    • \n
  • Implemented asynchronous CI/CD workflow list refresh functionality
    • \n
\n
", "url": "https://docs.tramline.app/changelog/august-19-2025", "title": "August 19, 2025", "summary": "Release-Specific notification channels", "date_modified": "2025-08-19T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/june-11-2025", "content_html": "

\n

Automatic version bumps​

\n

Up until now, to manage build coordinates (version name, build number) Tramline would send over the right values to the triggered workflows so that the correct build could be generated; this ensures that Tramline is always the source of truth for version management.

\n

However, this system has a limitation. It makes tracking the versions in the source a bit hard. One either has to write the version names manually to the build files like build.gradle, pubspec.yaml etc or maintain a script that reads the values sent by Tramline and then run some script to do it.

\n

Tramline now introduces two version bumping strategies that automatically create a PR to write the versioning info against some supported build files.

\n
    \n
  1. Current version (to working branch) before release branch is cut
    2. \n
  2. Next version (to working branch) after the release branch is cut
    3. \n
\n

The following build files are currently supported:

\n\n

We will continue to extend this feature to add support for more file types, custom versioning files and more granular strategies in the future.

\n

Branch prefixes​

\n

Quick quality-of-life improvement, you can now add prefixes to some of the automatic branches we create from Tramline. <prefix>-version-bump or <prefix>-patch-main. Note that prefix or any branch name modification is not supported for the release branches themselves currently.

\n

Fixing Releases on GitHub​

\n

\n

For GitHub VCS integrations, when we cut tags related to the releases, we also allow creating GitHub Releases against them. Previously, this experience was sort of broken because the GitHub API to create tags with releases is unreliable. It often internally blows up if the changelog for the release is too big (to workaround this, we would send Tramline's own copy of the changelog). Secondly, it also isn't very predictable in terms of the two tags it picks for the changes. Sometimes the previous tag picked is arbitrarily quite far back in time.

\n

We've fixed these longstanding issues and now always generate the correct changelog between the correct tags and retain the formatting style of the changelogs from GitHub.

\n
Improvements and Fixes
\n\n
    \n
  • Hide previous releases paginator if there are too few releases to show
    • \n
  • Add confirmation message before refreshing Slack channels
    • \n
  • Allow resubmitting the same iOS build again
    • \n
  • Show search results in reverse chronological order
    • \n
\n
", "url": "https://docs.tramline.app/changelog/june-11-2025", "title": "June 11, 2025", "summary": "Automatic version bumps", "date_modified": "2025-06-11T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/may-10-2025", "content_html": "

\n

Search through releases​

\n

Being able to find a needle in the stack of all your releases from the past has been a highly requested feature, and we're excited to ship the very first cut of this. You can simply press / anywhere on the Tramline dashboard and it will take you to the search page. This search page now also engulfs the previous (and limited) search functionality around finding builds against the versionCode and/or versionName.

\n

It's a powerful way for developers to find the release that shipped a particular feature or bug. We search through commits, authors, pull requests, labels, ticket numbers and map that onto the release they went out in. This is otherwise tricky to do manually via Git or Git interfaces without diligent and extensive annotation and tagging of changes. Since Tramline is a system of record for everything about releases, this is a big (free) unlock.

\n

For example, you remember a tidbit of a feature or bug, say the word, \"highlight\". You've forgotten the context and the details of the feature, so you just search for the term and you'll see all the pull requests and commits that match, narrowed down to the release in which they were first introduced.

\n

\n

This is a powerful debugging and auditing tool that doesn't require any extra state management in source control or sifting through changelogs on Slack.

\n

Skip the next scheduled release​

\n

\n \n

\n

A quick quality-of-life enhancement for scheduled release users, allowing you to skip just the next upcoming release (not the future ones). This is actually helps cover up a lot of existing limitations with automatic scheduled releases:

\n
    \n
  1. You can skip, cram more work in the last moment and then release it later manually
    2. \n
  2. You can skip, and release a major version, since scheduled releases only bump up minor
    3. \n
  3. You can skip, and forego that week's release, for when there are short holidays and such
    4. \n
\n

This is different from the current \"deactivate\" functionality, that disables all the scheduled releases and the entire release train indefinitely.

\n

VCS integrations can be disconnected​

\n

\n \n

\n

VCS providers don't really change that often, but this feature is particularly useful when you're changing accounts within the same VCS provider, for example, you're moving from a regular GitHub account to an enterprise account, or if you're using Bitbucket, and you're switching the owner of the integration to be a different user, you can simply disconnect the current integration and reconnect it in the new way. This does not affect the state or data of any of the previous releases against the previous integration.

\n

Workflow triggers gracefully fail​

\n

Tramline so far, has always synchronized the state of the workflows that generate different types of builds. But sometimes, especially when initially setting up the release, workflow failures can be a bit of a pain to debug. Errors such as missing workflow_dispatch configs, invalid input parameters, etc., are now clearly surfaced on the dashboard.

\n
Improvements and Fixes
\n\n
    \n
  • Increase the max number of pages for fetching repositories in Bitbucket
    • \n
  • If a PR closes during a Tramline-attempted merge, accept and move on
    • \n
  • Allow resubmitting the same iOS build again
    • \n
  • All input selections now have an upper limit of 100 items
    • \n
\n
", "url": "https://docs.tramline.app/changelog/may-10-2025", "title": "May 10, 2025", "summary": "Search through releases", "date_modified": "2025-05-10T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/february-18-2025", "content_html": "

\n

Reuse Integrations across apps​

\n

Tramline now allows reusing integrations from other apps in your organization, and also from within the same app. For teams with multiple apps, access to third-party integrations like Slack and GitHub are often not accessible to the user setting up the app on Tramline. If multiple apps use the same underlying integration, you should now no longer be blocked on your Ops/Support teams for access.

\n

\n \n

\n
info

If you only have one app, you can still reuse integrations across some categories. For example, you can reuse GitHub for both Version Control and CI/CD.

\n

Better editing experience for Release Notes​

\n

\n

The validations on iOS are much more strict and the error messages are clearer. Emojis and various other character rules are now disallowed, including the < character in particular.

\n

Each input field: Release Notes, Promo Text and What's new now have character count hints at the bottom. The input does not disallow adding more, but only hints at trimming down so you can rewrite as necessary. Additionally, the input areas now also auto-resize as you type.

\n

Custom parameters for workflows​

\n

For both Internal and RC workflows, you can now add custom parameters that get passed to the workflows or jobs triggered by Tramline. These can be set in the submission settings. This is helpful when you have the same workflow doing different things based on external parameters, e.g. making a staging build and production build from the same workflow file.

\n

\n
info

These do not affect the default workflow parameters that Tramline already sends for versionCode, versionName, commitRef etc.

\n
info

Ensure that you gracefully accept the custom workflow parameters in your workflow job, otherwise the workflow trigger could fail.

\n
Improvements and Fixes
\n\n
    \n
  • Paginate the historical releases
    • \n
  • Reduce fetch frequency of release metrics from Crashlytics
    • \n
  • Fetch release metrics from Crashlytics only after rollout start
    • \n
  • Avoid fetching release metrics for stale production releases
    • \n
  • Better notification messaging for when the release ends
    • \n
  • Allow retries for failed rollouts for Google Play Store
    • \n
  • Avoid \"Edit has been deleted\" errors from Google Play Store
    • \n
  • Open up view-only access to configuration screens for viewers
    • \n
\n
", "url": "https://docs.tramline.app/changelog/february-18-2025", "title": "February 18, 2025", "summary": "Reuse Integrations across apps", "date_modified": "2025-02-18T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/january-20-2025", "content_html": "

\n \n

\n

CalVer 📅​

\n

In addition to a SemVer-like versioning scheme, we now also support a calendar-based versioning scheme. Stores (both Apple and Google) don't particularly support one scheme or another, and neither are they very particular about the adherence to a spec. App Store, for example, suggests a roughly SemVer-like format for build versions and Google Play Store is pretty free-form.

\n

Since Tramline automatically manages versions for you, we categorize them into specific versioning schemes so that the increments are predictable.

\n

For example, In SemVer, we allow the following versions:

\n

✅ Allowed

\n
1.2.0
4.2.1
16.9
\n

❌ Invalid

\n
1
1.2.3.4
1.02
\n

With CalVer, we use the following scheme:

\n
YYYY.0M.0D0N

YYYY = Full-year
0D = Zero-padded day
0M = Zero-padded month
0N = Zero-padded sequence number
\n

✅ Allowed

\n
2025.01.20
2022.02.01
\n

❌ Invalid

\n
25.1.20
25.1.32
2025.1.1
\n

\n

The sequence numbers are used to track patch updates. For example, if you start rollout on 2025.01.20 to the store, but you add a patch update before it completes, the next version will be 2025.01.2001.

\n

Manual retries for submissions 🔁​

\n

\n

We now finally support retrying failed submission for any submission channel. This is a highly requested feature, but due to the complexity of tracking resumability of different submission states, we delayed it until we got it right. For most known issues or one-off errors, we already internally retry. But now it should be possible to manually retry issues that escape our internal error handling or automatic retries.

\n

Build suffixes for Android builds 🪜​

\n

\n \n

\n

When configuring submissions, you can now add a suffix to the version name that is assigned to the build. This is useful for segregating build versions (and release names) clearly in different submissions channels like Firebase / Play Store.

\n

For example, if you setup a suffix staging, the version name will become 1.0.0-staging.

\n

Archiving team members and invites 🗑️​

\n

\n

Previously, owners could only edit roles of team members, now they can also remove them. When users are removed, they are soft-deleted or archived and not actually deleted from the system. This is why we avoid the terminology of delete. Pending invites, however, are permanently deleted.

\n

For SSO users, removing a user does not revoke their SSO access from the IdP (identity provider), which means they can always log back in as a viewer. On the flip side, if they are removed from the IdP, they aren't automatically kicked out from Tramline, however, they naturally won't be able to login (and can be cleaned up from Tramline if necessary).

\n
Improvements and Fixes
\n\n
    \n
  • Fix bug that disallowed role change for SSO users
    • \n
  • Allow automatic scheduled releases to start upcoming releases
    • \n
  • Show a snapshot of recent events in pre-prod releases
    • \n
  • Finalizing a release should only check for PRs created by Tramline
    • \n
\n
", "url": "https://docs.tramline.app/changelog/january-20-2025", "title": "January 20, 2025", "summary": "CalVer 📅", "date_modified": "2025-01-20T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/december-30-2024", "content_html": "

\n \n

\n

Release Health Monitoring – Firebase Crashlytics​

\n

Tramline continously monitors the release health of an app by listening to signals and metrics from dedicated monitoring tools and condensing them down through a release lens. Along with Bugsnag, we now also support Firebase Crashlytics.

\n

This integration works by internally integrating with two tools: Google Analytics and Crashlytics itself.

\n

Crashlytics by itself isn't feasbile for calculating aggregate stats like crash-free rate or adoption rate, because it only contains info on unhealthy sessions; without info on healthy session stats, there is no denominator for crash-free rates or adoption. This denominator is pulled from Google Analytics.

\n

This feature is in beta as we're still collecting feedback and data from our users and will be publically available early next year.

\n

Copy approvals from previous release​

\n

\n

We have extended our stakeholder approvals feature to now automatically copy over approval items from the previous release to the next one. This cuts down work for teams who want a similar set of approval items in each release assigned to a bunch of different people.

\n

Even if you don't have the automatic setting on, you can still copy them over from a single click after the release starts.

\n

Combine commits in a single push in patch PRs​

\n

\n \n

\n

When creating patch PRs (for continuous backmerges), Tramline now combines all the commits from a single git push (to the release branch) in a single pull request. This reduces the number of changes that need to be reviewed and merged, and cuts down on general PR noise.

\n

Auto-retry merge failures for pull requests​

\n

\n \n

\n

For all kinds of pull requests in Tramline, namely:

\n\n

Whenever Tramline creates these, we always try to merge them right after. Apart from merge-conflict related reasons, we are often unable to merge because of various pre-merge checks. For some VCS integrations (like GitHub), we handle this gracefully by enabling post-check auto-merges. But in cases where that's not possible, Tramline now continously tries to merge until checks pass. So if there's a human or bot dependency that's blocking the merge from immediately happening, the merge from our side is still largely hands-free.

\n

For conflict related errors, Tramline clearly marks those PRs on the dashboard as such so that they can be manually resolved.

\n

Allow fixed build version for releases​

\n

\n

This is useful for non-production / nightly releases where you don't care about the actual version name (like 1.2.3), you just need to generate and distribute new builds. Turning this on will fix the version name across all releases for a train. Note that this does not affect the version codes, they get bumped normally as expected.

\n
Improvements and Fixes
\n\n
    \n
  • Add rollout percentage to store version APIs
    • \n
  • Remove all previous code from before a major Tramline rehaul
    • \n
  • Run specs on docker
    • \n
  • Improve page titles
    • \n
  • Allow upcoming releases to start when rollouts are paused in the current
    • \n
  • Handle CRLF/LF in release notes consistently
    • \n
  • Paginate Bitbucket APIs when listing repos
    • \n
  • Handle lack of millisecond-precision for multi-commit git pushes
    • \n
\n
", "url": "https://docs.tramline.app/changelog/december-30-2024", "title": "December 30, 2024", "summary": "Release Health Monitoring – Firebase Crashlytics", "date_modified": "2024-12-30T00:00:00.000Z", "author": { "name": "Guru Pratap", "url": "https://github.com/gurupratap" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/november-27-2024", "content_html": "

\n

Cascading rollouts​

\n

With Google Play Console, when you update your rollout to a 100%, it is not possible to halt it, even if in reality the actual rollout hasn't farmed out to all of the 100% of users yet.

\n

For example, if you have 100 users, and your rollout sequence is 10%, 50% and 100%, and once you actually move the rollout to 100%, it is possible that number of users/sessions that actually receive the update is still much less than 100. Since a halt isn't possible on the Play Console at 100%, teams usually have a workaround to release to 99.9%. This allows them to halt the rollout until as late as possible.

\n

Tramline now natively supports this process; you can set your rollouts to be cascading, which will only rollout to 99.9% (or your final rollout value of choice) and prevent you from starting the rollout of the next release until the previous one is moved from 99.9% to a 100%.

\n

This entire flow is managed and prompted through appropriate callouts and actions during the release process.

\n

Continuous backmerges without cherry-picks​

\n

every commit. However, this method is unfortunately integration-specific, as not all VCS providers support cherry-picking through APIs.

\n

\n

Specifically, Bitbucket doesn't support cherry-picks or even mimicking a cherry-pick, so we do the following:

\n\n

In this mode, subsequent patch branches could have more than one commit, if the previous ones are unmerged. So we recommend merging everything as soon as possible and in the correct order to avoid confusion.

\n

Re-fetch workflow status​

\n

\n \n

\n

Until now, Tramline allowed you to re-trigger workflows if there was a failure in the runs. Now, additionally, you can simply re-fetch the status of the workflow run instead of retriggering. This is especially helpful when you don't want to retrigger the entire workflow but can just re-run the specific failed jobs and have them sync on Tramline.

\n
Improvements and Fixes
\n\n
    \n
  • Stricter validation for release notes for each platform
    • \n
  • Submission configuration is now optional for internal testing
    • \n
  • Do not auto-stop a scheduled release on post-release failure
    • \n
  • Do not allow -ve values in reldex computation
    • \n
  • Allow a different set of supported languages for Android and iOS
    • \n
  • Truncate commit messages in notifications to adhere to Slack limits
    • \n
  • Notifications around internal submissions finishing
    • \n
  • Generally nicer cues for showing progress in live release
    • \n
  • Optimize load times for the Release Activity page
    • \n
\n
", "url": "https://docs.tramline.app/changelog/november-27-2024", "title": "November 27, 2024", "summary": "Cascading rollouts", "date_modified": "2024-11-27T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/november-12-2024", "content_html": "

\n

Approvals​

\n

Tramline now has an approvals system that allows you to add high-level approvals from various stakeholders for the release.

\n

During a release, the release captain can add tasks to be approved by any set of members in the team. When a task is assigned to a team member, they receive an email notification.

\n

\n

The assignees of the task can mark the task as approved, blocked, or in-progress. The release cannot be sent to the production track on the stores until all the approvals are complete.

\n

The release captain can choose to override the approvals for a release. This is useful for rare scenarios where there is an urgency in getting the release to production and the team members are unavailable for the required approvals.

\n

If the override is used, it will be reflected on the release activity page for auditing purposes.

\n

The configuration to enable approvals for the release can be found in the Advanced Settings of the release.

\n

Edit roles of team members​

\n

You can now edit the roles of your team members in the team section of the Organization Settings page.

\n\n

The owners and developers in the team can edit the roles of the developers and viewers, respectively.

\n

This is especially useful for teams with SSO enabled. With SSO, any member of your organization can log in to Tramline as a viewer. You can choose to change the role of the user to the most appropriate one once they have joined your team in Tramline.

\n

Re-use the same integration for multiple categories​

\n

You can now re-use the same integration for multiple categories. This reduces the number of connections required for onboarding a new app.

\n

\n
Improvements and Fixes
\n\n
    \n
  • Enhance FAD build upload check to search by build number and version name
    • \n
  • Auto-detect file extension for build archive files when not provided
    • \n
  • Send branch context to Bitbucket when triggering pipeline for commit
    • \n
  • Ensure submissions get picked up in the correct order
    • \n
  • Set the app time zone correctly on the live release pages
    • \n
  • Fix default production submission config for Android
    • \n
  • Fix resume action for app store rollout
    • \n
  • Handle a phased rollout on the App Store when it's already complete
    • \n
  • Pick active locales only from the production track for Play Store
    • \n
  • Fix \"changes since previous\" to handle unapplied commits
    • \n
  • Add missing locale string for rollout getting updated
    • \n
  • Add a warning to show until which release step the notes can be edited
    • \n
  • Fix health metric jobs to stop fetching after the monitoring period
    • \n
\n
", "url": "https://docs.tramline.app/changelog/november-12-2024", "title": "November 12, 2024", "summary": "Approvals", "date_modified": "2024-11-12T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/october-13-2024", "content_html": "

\n

The work pane (live release page)​

\n

Tramline is conceptually a relatively rare paradigm of DevTools. Other \"release management\" DevTools on the server-side like Heroku can operate more or less solely through a CLI. For most teams, Tramline is a high-touch tool where a lot of people end up collaborating. It is as much a GitHub as it is a Heroku.

\n

This is why a more-than-default thoughtful design is necessary for Tramline. It is important so that people can get used to the \"right flow\" for releasing apps.

\n

From this lens, we've made two broad changes.

\n
    \n
  1. Porting our design over to the \"work pane\"
    2. \n
  2. Simplifying the building blocks for configuring a release
    3. \n
\n

Layout & design​

\n

The work pane is auto-structured into four main sections:

\n

\nOverview: Issue tracking, changeset tracking and the homepage for the Release Captain.\n

\n

\nStability: Internal builds, Release Candidates, testing.\n

\n

\nMetadata: Dedicated space for updating notes, store metadata and screenshots.\n

\n

\nStore Release: Managing reviews and rolling out to production.\n

\n

Previously, the work pane was one giant page, and even though there's some value in everything in one single page; it is a nightmare of information architecture and page load times. More specifically, categorizing them allows us to clearly differentiate historical state, present state and future state across different events.

\n

Improved UX around app submission​

\n

Because the design allows for more breathing room, we can focus on individual aspects of the release a bit better.

\n

For example, there's a lot more control around app submission. You can cancel a running review in progress and you can also replace the build for an existing review with a new one or a previous valid one.

\n

\n \n

\n

Similarly when rolling out, the entire page doesn't get filled with a lot of rollout data, there's a dedicated place for it:

\n

\n \n

\n

Not just tabs​

\n

\n \n

\n

The tabs are alive — they always track the current state of that section — whether it's in progress, completed or pending. They also automatically get switched over to the most important tab in the current release and they disappear if they aren't necessary to the current release.

\n

Configuring the release​

\n

We have now thrown away all the bloated abstractionware of Steps and Deployments and instead we just deal with Submissions. The interface to configure them is a single pane to setup everything about your release and will continue to grow down this path.

\n

\n

Trying to be clever with our release abstractions and modeling them after CI/CD pipelines was a mistake. We now model things around actual user patterns.

\n

Support for multi-locale release metadata​

\n

We now also support updating multiple languages for the release notes. When you start your release we pick up your last updated release notes, which you can edit before release.

\n

On top of this, we also support updating multiple languages for both iOS and Android (for cross-platform apps) from the same place!

\n

\n

Remove Slack as a submission integration​

\n

Slack was previously available as a submission integration so that you could send builds to a channel. This is still supported, but as a part of the notification configuration itself.

\n

We've been wanting to make this change for a bit because it makes the purpose of each category very clear. Integrations that distribute should be integrations where the primary purpose is to distribute, it's not enough that they can optionally help distribute. Slack is foremost a team chat tool, and file server later.

\n

This is only applicable to new apps, existing apps with Slack as a submission integration will be gracefully ported over.

\n

App Variants with their own integrations​

\n

\n

Late last year, we added support for adding multiple bundle identifiers within a single primary app under App Variants. This helps support flavors of the same app being distributed to different submission channels. We've gone a step further, and allow configuring a different account/integration altogether rather than just using the existing primary app integrations.

\n

\n
note

App Variants still only support Firebase App Distribution at the moment. We will be adding more integrations in the future.

\n
Improvements and Fixes
\n\n
    \n
  • Ensure all API-call based user actions are async
    • \n
  • Fix UI issue around showing 100% rollout correctly for non-staged rollouts
    • \n
  • Ensure there are valid build workflows available before allowing train creation
    • \n
  • Fix the password reveal toggle in the signup form
    • \n
  • Show a generic flash message instead of a full 500 page
    • \n
  • GitHub release notes are now well formatted and respect automatic notes
    • \n
  • Dockerize the entire dev setup
    • \n
\n
", "url": "https://docs.tramline.app/changelog/october-13-2024", "title": "October 13, 2024", "summary": "The work pane (live release page)", "date_modified": "2024-10-13T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/september-17-2024", "content_html": "\n

Bitbucket support​

\n

We now support Bitbucket both as a VCS and a build server integration. As with other integration categories, Bitbucket falls neatly in our abstractions but with two primary exceptions.

\n

First, Bitbucket doesn't allow us to pull builds from pipelines directly. You can upload them to the Downloads section for your repo via the upload-file pipe. We will soon release a custom pipe that wraps this and makes setting everything up even simpler.

\n

\n \n

\n

Second, Bitbucket doesn't provide us a way to cherry-pick commits (either manually or automatically) from the API, so continous backmerges are currently turned off for this integration. We'll push an update as soon as we have a way around this.

\n

That's it! The rest works precisely as Tramline is meant to work.

\n

SSO improvements​

\n
    \n
  1. \n

    If you're an SSO-enabled org, you now don't need to invite viewer users, all SSO users can self-join automatically as viewers. For write-enabled (developer) users, you would still need to go through the invite flow as usual.

    \n
    2. \n
  2. \n

    Until now, you could have both email-based authN and SAML-based authN working together. Now, if you're an SSO-enabled org, no other auth mechanism is allowed.

    \n
    3. \n
\n
Improvements and Fixes
\n\n
    \n
  • Improve integration/config onboarding wizard
    • \n
  • Add a banner to prompt users to complete their profile
    • \n
  • Handle new Play Store errors – foreground services and account issues
    • \n
  • Handle unauthorized errors from App Store properly
    • \n
  • Allow internal testing releases when app is in draft mode
    • \n
  • Allow hotfix for a cross-platform app when one platform has started rollout
    • \n
\n
", "url": "https://docs.tramline.app/changelog/september-17-2024", "title": "September 17, 2024", "summary": "Bitbucket support", "date_modified": "2024-09-17T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/august-3-2024", "content_html": "

\n

Single Sign-On Support 🔑​

\n

SSO (via SAML) is now available as an authentication method in Tramline. Once enabled, all users in the organization will be required to sign in using the SSO provider.

\n

To simplify the setup and management of SSO, we use a third-party auth service provider. However, we continue to maintain our existing email/password login natively, i.e, without relying on any third-party dependencies. This allows open-source users to self-host Tramline without the need for setting up additional accounts outside.

\n

With this, the user access management to Tramline can be centrally managed by companies and their IT teams. This is a big step for Tramline towards supporting enterprise organizations!

\n

New Reldex components 📊​

\n

We rolled out Reldex to all users in our last major release. We have since added a few more optional components to the Reldex score:

\n

Days since the last release​

\n

The number of days since the last release to production was made. This is a good indicator of how much you are sticking to your regular release cadence. This is an indirect measure of drops in your deployment frequency.

\n

Number of rollout changes / patch fixes​

\n

Tramline classifies changes in the following ways:

\n\n

This component now takes the \"Patch fixes\" into account separately, along with Stability changes and Hotfixes.

\n

Patch-version bumps across releases 🤛​

\n

You can now configure your release train to only bump the patch version across new releases. This is especially helpful for daily/weekly scheduled releases, where you don't want too many minor version bumps constantly as each subsequent change is likely trivial.

\n

\n

Upcoming release without internal builds 🚂​

\n

The upcoming release feature is now available for release trains that directly ship to beta/production (without any internal builds). This allows you to prepare the next release while the current one is still in progress. This is especially useful for teams that have a long beta period and want to get a head start on the next release.

\n
Improvements and Fixes
\n\n
    \n
  • Add Indian+Indonesian languages to list of locales for release notes
    • \n
  • Gracefully handle lack of apps in iOS or Android projects on Firebase
    • \n
  • Handle double-quotes inside build notes when distributing
    • \n
\n
", "url": "https://docs.tramline.app/changelog/august-3-2024", "title": "August 3, 2024", "summary": "Single Sign-On Support 🔑", "date_modified": "2024-08-03T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] }, { "id": "https://docs.tramline.app/changelog/may-12-2024", "content_html": "\n

Introducing Reldex (release process index) 📊​

\n

We are excited to introduce Reldex, a new metric and scoring mechanism that helps you understand the efficacy of your release process.

\n

It combines various signals like release duration, hotfixes, time taken to rollout, and fixes during stabilization to give you a single score (between 0 and 1) that represents an overall quality of the delivery process.

\n

This is different from the post-release monitoring of the health of a release based on signals from APM and monitoring tools. Reldex measures everything before or during delivery, rather than the stuff after the release has been rolled out.

\n

\n \n

\n

Reldex is enabled by default and available to all users, both free and paid. You should already be seeing this score show up on your dashboard. It comes pre-configured with some sensible defaults, but you can fine-tune it based on how you want to weigh and prioritize the importance of each of the signals. Read more about Reldex → here.

\n

Allow continuous scheduling despite previous failures 🚲​

\n

\n \n

\n

Tramline currently halts the scheduling of an automatic train if the last release failed, but was not explicitly stopped. This is a safety mechanism to prevent a series of failures.

\n

With the new option of Automatic stop on failure under scheduled releases, Tramline will automatically stop a failed release so that a new one can be scheduled and kicked off. This is useful when you're confident that the failure was a one-off and/or you don't want to handhold scheduled releases.

\n

Less noise when generating automatic tester notes 🎧​

\n

When generating automatic commit-based tester notes, we now only consider the first parent when encountering a merge commit. Since Tramline doesn't actually checkout code, we manually simulate git log [range] --first-parent to get the correct set of commits needed to generate the appropriate notes.

\n
Improvements and Fixes
\n\n
    \n
  • Auto-populate release notes from previous release for a new release
    • \n
  • Add a note about Slack file upload requiring Tramline to be invited to channel
    • \n
  • Ensure that GitHub integration exists with a mandatory installation_id
    • \n
  • Show the last 15 releases on the team page instead of 10
    • \n
  • Add checks for duplicate-actions for all phased rollout related triggers
    • \n
\n
", "url": "https://docs.tramline.app/changelog/may-12-2024", "title": "May 12, 2024", "summary": "Introducing Reldex (release process index) 📊", "date_modified": "2024-05-12T00:00:00.000Z", "author": { "name": "Akshay Gupta", "url": "https://github.com/kitallis" }, "tags": [] } ] }