Release ATC: an AI-powered chatbot for release info and actions
We're very excited to announce Runway's new Release ATC: you can now chat with the Runway Slack app in DM to get all your release questions answered and even take actions on releases.
We wanted to make it dead simple for anyone on your team to access everything Runway knows about your releases and to handle tasks needed to move release cycles forward—without them having to leave the one tool they use most for day-to-day collaboration and communication. Access is scoped by Runway's granular user permissions, so everyone automatically has the ability to do exactly and only what they're allowed to do, with no extra oversight needed.
To get started, just open up a DM with the Runway Slack app and say hello!
New tabular views to see release data across multiple apps and releases at a glance
We've rolled out a new style of tabular view at both the org and app level that lets you quickly scan release information and status across multiple apps and releases—even dozens of them—all in one place. You can customize exactly what data is shown, making it easy to focus on the metrics and information most relevant to your team. This is especially useful for stakeholders who need the bigger-picture view across a mobile org, and for cross-platform teams or those that manage whitelabel apps.
Currently available in closed beta — reach out if you’d like early access.
Add custom content to any notification
Sometimes you need to include additional context or instructions in the notifications Runway sends, beyond what’s included by default. You can now append custom text to any notification, and with Runway’s pattern tokens this custom text can be dynamic, allowing you to pull in relevant information like build numbers, release pilot names or even work item diffs.
Powerful new options for customizing how and when automations run
You now have much more control over Runway’s automations with a number of new ways to configure them beyond their default behavior. Target deadlines can be set per automation such that they trigger at specific times relative to your release milestones – for example, run a particular CI workflow four hours before your scheduled submission, or start auto-assigning testers to beta builds 12 hours after your release kicks off. Or, configure gating conditions that require previous release steps to be completed before an automation proceeds. You can also combine both approaches, running an automation with specific timing but only if certain steps are “green”. And, you can now also control which release types a certain automation can run for, giving you even more ways to segment your process between normal releases and hotfixes.
More ways to filter Feature Readiness for monorepo teams
Because the Feature Readiness view in Runway defaults to showing a full release diff—from previous tag to HEAD of the release—teams using monorepos will find that a lot of items unrelated to the app in question are included. In addition to the filtering that’s already possible via the Feature Readiness UI, there’s a new way for monorepo teams to configure more permanent filtering that will cause Runway to only surface items whose commit messages, PR titles, or PR labels contain certain keywords. Unlike the UI-based filtering, this also ensures that downstream automations on Feature Readiness (e.g. auto-applying labels or fix versions to project management tickets) only act on the correct subset of items.
Automatically pause your release schedule and automations during code freezes
Are you a retail app heading into Black Friday or a sports app heading into the Super Bowl? Instead of needing to manually disable your release schedule and related automations (e.g. auto-kickoff, submit, and release) in Runway, you can now configure “lifecycle freezes” that will automatically put your train on pause during selected dates. Once outside the window, Runway will either resume the in-progress release or kick off a new one based on your schedule.
Safeguard build selection based on regression testing results, and more options for regression testing behavior
Runway’s automatic app store build selection is an efficient, hands-free way to ensure you’re always ready to submit, but if your team tends to distribute many builds to the stores, you need to be very clear and careful about which one is the final RC that you want to ship. You can now configure the build selection automation to “lock” to whichever build is selected and marked as passed on the Regression Testing step, rather than always defaulting to the latest available build.
To give you more ways to manage how regression works within Runway, you now have four different options for how the Regression Testing step behaves when it comes to builds and statuses. You can choose to have the step clear the currently selected build and regression status whenever a new build is detected, automatically update to any new build and reset status to "In progress," keep build and status selection manual, or disable explicit build and status selection entirely and let Runway determine the overall regression result based on individual regression testing items you’ve configured.
Early warnings and more control over rollout health alerting
We’ve made some updates to our popular rollout health alerts to give teams an earlier indication of impending problems and to help avoid any signal-to-noise issues. Now, for any given health metric you have configured, you can opt in to receiving warning notifications if they approach within 10% of their unhealthy threshold, in addition to the usual alert if they actually cross into unhealthy territory. In the notification’s settings, you can also configure exactly when these alerts should start sending based on adoption percentage or day of rollout, allowing you to fine tune your signal-to-noise ratio based on sample size.
A new, more configurable strategy for automated backmerges
Runway’s backmerge automation now supports a third backmerge strategy. In addition to options to backmerge all changes once at the end of the release cycle or backmerge continuously per change, you can choose to cherry-pick changes continuously from the release branch to your working branch branch. This approach gives you more control: you can configure the automation to skip certain kinds of pull requests (e.g. late changes that were pulled over from your working branch in the first place), or skip changes that affect certain file types that you don't want backmerged (e.g. avoid backmerging unsquashed PR commits in favor of the merge commit only). As always, if merge conflicts occur, Runway will notify you and create a timeline event so you can resolve and move on.
Bookmark-friendly URLs that automatically resolve to the right release
For folks that want to save quick links to their most top-of-mind releases—perhaps to add to some internal documentation, to pin to a Slack channel—a new kind of dynamic URL is available. Instead of bookmarking and then re-bookmarking specific releases, you can now use special path parameters like next and live to always be taken to the correct place. For example, …/releases/live/rollout/summary would always take you to your current version’s rollout page. For folks that are in-office, this is especially useful for throwing Runway dashboards up on a big screen.
Manage release checklist items at the org level for all of your apps
To make it easier to manage parts of your release process that should be standardized across multiple apps, you can now create and edit checklist items at the organization level. Org-level checklist items automatically populate to all releases across all apps in your org, eliminating the need to manually recreate checklist items that each app has in common and keep all of those updated if they need to change along the way. This is particularly valuable for teams with standard compliance, legal, or other sign-off tasks that should be part of the release process for all apps.
More ways to pull fixes into releases and manage the fix lifecycle
We’ve enhanced Fix Requests and cherry-picking in Runway so teams can pull in fixes earlier in the development lifecycle, track those fixes more easily, and clean them up with less manual effort. First, you can now get fixes on the radar as soon as you know they’ll be needed for a particular release—well before work on them has necessarily started—by selecting from among any and all project management tickets in the fix creation flow, not just those already associated with the release and regardless of whether code changes already exist. If needed, Runway can also automatically apply the appropriate fix version or label for the release in question when you create a fix this way.
Other changes make it easier to manage and track the lifecycle of fixes. Now, if an engineer removes a cherry-pick token from the title of a PR associated with a fix (maybe the fix is no longer needed or it won’t be shipping with the release in question), Runway will automatically remove the fix and post a timeline event explaining what happened. In situations where multiple project management tickets are referenced by the same code item and that code item is part of a fix, Runway now associates both tickets with the same fix, rather than creating separate fixes for each ticket. This prevents issues where duplicate fixes could be out of sync or where PR status checks might be overwritten.
New integrations: Apple Power & Performance Metrics, Jira Service Management
We have a new 'Observability & Analytics' integration available. Connecting Apple Power and Performance Metrics in Runway allows you to monitor launch times, memory and battery usage, terminations and more, and configure alerting and rollout automations based on defined thresholds. This gives you another data source to help catch performance regressions before they impact your users.
If you use Jira Service Management for on-call scheduling, Runway can now integrate with JSM to automatically manage your release pilot rotation based on your JSM schedule. This requires that you also have Jira connected as a project management integration, but once set up, your release pilot assignments will automatically stay in sync with your broader on-call schedule without any manual updates needed.
Even more granular app-based access control
By default, all users in a Runway org have at least read-only access to every app in the org. For many teams this works well, since they don’t mind that all teams and stakeholders are able to see what everyone else is up to, even if they’re not directly involved in a given app’s releases. But we also understand that there are situations in which a team would want app access to be locked down more. Building on top of Runway’s app membership functionality, we’ve introduced a new optional setting that, when enabled, requires that a user be a member of an app in order to even view any of that app’s data. If a user does not have access to a given app, they won’t even see it in Runway’s navigation.
Automatically pull a previous submission when skipping a release
The “skip” functionality in Runway offers a quick way to move past a given release cycle if you’re no longer going to ship that version to prod (if a critical bug was identified during regression, say, and you’ll fix forward in the following release instead of delaying the previous). There are a number of automations that run when you skip a release, to ensure that state is correctly cleaned up across all the tools involved, and we’ve added another option to help you move past a problematic release even more seamlessly. Now, when skipping a release on the Apple side, you can have Runway automatically pull any previously submitted build, since that would otherwise block your ability to move on to the next version.
More accurate release calendar predictions for accelerated rollouts
The release calendar views in Runway – and resulting data synced to your team’s internal release calendar, if integrated – are designed to not only surface concrete release milestones but also upcoming release and rollout timing based on historical data. This is especially helpful for managing stakeholder expectations around version availability, but for teams with Runway’s rollout acceleration automation enabled, the calendar’s illustration of rollouts could be misrepresentative. Now, if your team has Runway configured to accelerate stable releases to 100%, the release calendar will factor that in and display the optimistic rollout schedule assuming acceleration (with messaging alongside to make that clear).
More ways to navigate automation and notification settings
We understand that managing your Runway automation and notification settings can be tricky, especially as our list of available automations and notifications grows. To help with this as well as improve discoverability of new automations and notifications your team may want to leverage, we added new sort options to Runway’s automation and notification settings pages.
