Up until now, cross-platform and whitelabel teams have managed releases under separate apps in Runway. While our automations helped streamline things as much as possible for teams fitting into these common use cases, we knew the experience could be made even better for shipping “one to two”, and especially for “one to many”. Our Workflows project has seen us rebuild Runway from the ground up to more naturally accommodate the different ways the mobile world ships apps, not just for cross-platform and whitelabel, but for any team wanting to customize Runway further to fit their way of releasing.
The first big set of Workflows changes to become available in beta allows your team to configure multiple Beta testing, Submission, Review, and Release steps within a given app in Runway. This means a cross-platform team can now set up a unified process for their Android and iOS releases that follows a single pathway from Kickoff until Beta testing or Submission, at which point it splits into platform-specific store steps that allow for managing both sides in one place. Similarly, a team shipping 10s or 100s of whitelabel apps can seamlessly manage releases for all of those in a single workflow.
In addition to “parallelized” workflows like the ones just described, these Workflows changes unlock the possibility of having multiple “serial” steps of a given type. So with the Beta testing step, you can now have more than one of those per release — allowing for a couple of discrete stages of pre-prod distribution, e.g. Alpha and then Beta.
If you’re interested in trying out the Workflows beta for your apps, just reply to this email!
And there’s a lot still to come on the Workflows front, as we expand support to cover more Runway release steps, add the ability to take bulk actions and automate more across steps, and introduce new summary views and overviews.
Automation is great for obvious reasons, and it’s a big focus in Runway. However, we recognize that increasing automation in your release process can also introduce more “black box effect”, with lots happening under the hood and less immediate visibility into what’s happening, and why (especially when automations fail). Building on other recent changes to event timelines in Runway — the revamped, dedicated timeline view, filtering, and additional events — we’ve expanded the footprint of automations in timelines.
First, given only a small subset of automations were previously captured in timelines, we reworked all of Runway’s available automations to ensure each one is fully captured in timeline data — whether one-off and release-level, or recurring and app-level. We also expanded the kind of data that’s captured and surfaced, to ensure you have full context alongside each and every automation run. In addition to including more info around status, Runway also saves and surfaces the exact settings that were configured at the time the automation ran.
Teams use Runway’s checklist and approval items to capture parts of their release process that can’t or shouldn’t be automated — e.g. certain manual actions or updates that different folks on the team need to take care of throughout a release. You can locate these items in different steps within your release workflow to vaguely position them in time relative to the release cycle. But, the reality is that these kinds of actions often need to be taken at specific moments. You may have a reminder that needs to go out three days before kickoff, and simply having a corresponding checklist item on your Kickoff step doesn’t make that very clear.
Now, you have the ability to attach explicit timing to your checklist and approval items. For example, you could make an item due “two days before kickoff”, “at submission time”, or “one hour after release”. When you attach timing to an item, that timing is surfaced clearly in Runway as a visual reference, and it can also power optional reminder notifications which fire if a deadline arrives and the corresponding item hasn’t been marked complete.
Runway’s hotfix flow is designed to help you get a hotfix up and running as quickly as possible when you need to address a critical issue in prod. You can have Runway cut a hotfix branch off your last tag, immediately bump the version on that branch, and even pull in fixes via automated cherry-picks. There are a few aspects of the flow that we previously constrained to ensure things are quick and consistent, but those constraints made handling certain edge cases less streamlined.
We’ve introduced a couple of changes to the hotfix flow to allow for more flexibility when things go further off the happy path. Now, you can explicitly select the base to cut a hotfix from — so if you need to start further back in history (say you already shipped a hotfix and it didn’t work out, so you want to restart with the ‘parent’ release instead) you have the ability to do that. Also, where Runway would previously hardcode a predicted hotfix version for you, you can now input a specific version number as needed.
Many teams use Runway’s fix request flow to safeguard their release diffs, requiring contributors to submit requests when they want to add late changes to a release. Formalizing the process for these requests and making them more visible helps teams stabilize releases better. And the details submitted alongside these requests play an important role, since they help explain why the late change is necessary and give reviewers the context they need to decide whether to let extra work in or not.
A few new changes in the fix request flow make it even more powerful. First, whereas before you could only create a new fix request if the corresponding code change was already in flight (e.g. PR with a fix open against trunk), now you can create a new fix request that references a project management ticket only. This way, you can raise a request as soon as a showstopping issue is ticketed up (and before anyone starts work on it), approve/reject, and track progress across the entire flow.
There are also new settings that give you more control over the details submitted with each fix request. You can now set a details “template” that will be prepopulated in the fix request form, both within Runway and via the Slack flow. This allows you to create sections and specific prompts that requesters will fill in and address. And, you can now make the details field required, so that the necessary context is always submitted alongside each request.
We shipped a number of new integrations at a couple of different integration points in Runway. Android Vitals is our latest observability & analytics integration, allowing you to surface Google-native metrics like ANR rate, slow start rate, excessive wakeup rate and, well, everything else Android Vitals measures. Like any other observability & analytics integration in Runway, you can surface this data during rollouts and define metrics with thresholds for alerting and rollout automations.
We also have two new testing integrations: BrowserStack and Qase. When you connect either of these, Runway will automatically pull in any test runs against a given release, surface live statuses as those progress, and track history across multiple sets of runs if needed. (For other testing integrations like these, Runway can also automatically create your test runs for you, release to release — that functionality will be available in future for these newest integrations.)
We know that many Jira teams work across a multitude of different projects, and that list of projects is often changing over time. Currently, you need to manually select each project you want in-focus in Runway in your integration settings, and keep the list of selected projects updated.
We’ve added an option on the Jira integration settings in Runway to automatically select all available projects, and keep the list of selected projects updated as projects come and go on the Jira side.
Given Pipelines and builds generated by Pipelines surface differently than Workflows and Workflow builds in Bitrise’s API, support for the former was only possible via a backend config on the Runway side.
To make setup easier for Bitrise Pipelines teams, we brought full support for Pipelines to the Bitrise integration settings UI.
Runway’s Google Calendar integration allows you to automatically sync your Runway release schedules and rollout info to an external team calendar, and also pull any additional events created in your team’s external calendar into Runway’s calendar views.
Google auth can be finicky when it comes to Calendar integrations, and the service account approach was proving difficult for some teams, so we added OAuth as an additional option for connecting Google Calendar. This allows you to integrate with your calendar via an individual user account in your Google Workspace.
