Introducing Fixes by Runway

Managing the work that makes it out with any given app release is tricky.

Late-arriving changes are directly correlated to increased bugginess in releases, so teams typically try to establish a stabilization period or “freeze” to prevent new changes from entering the diff while testing and other release prep is finalized. Actually enforcing that freeze can be difficult. It requires some combination of thoughtful branching strategy, branch protection rules, and well-documented processes that the entire team buys into, adheres to, and keeps up to date.

What makes this even trickier is that sometimes you do still need to pull late changes into a release. You can’t just lock the diff immediately after you kick off a release and call it a day, as issues are sometimes only identified during the stabilization period. This is especially true for teams that ship fast and frequently. Since final validation often happens in parallel with freeze and other release prep, it’s more likely that issues get discovered post-freeze. Plus, it’s possible that the preceding release is still early in its rollout, a critical issue is discovered there, and the team wants to squeeze a fix into the on-deck release.

The mechanics of actually getting late-arriving work into a release (and making sure all changes are synced with the working branch) involves extra Git wrangling (a cherry-pick or backmerge workflow, say), and that alone can be more insidious than you might expect. In a vacuum these aren’t difficult processes to run, but in a high-pressure situation where the team is rushing to get fixes in and avoid a delayed release, the extra wrangling is unwelcome busywork and context-switching. Given the context, it’s more likely that mistakes are made or steps are missed. (Teams that backmerge: ever apply a fix and then forget to backmerge, landing right back where you started with another broken release??)

Perhaps the hardest part of handling late-arriving work is deciding what actually gets to arrive late. Is anyone and everyone allowed to apply late fixes to a release if they feel like it? Could someone even squeeze in that last feature ticket they just managed to finish post-freeze but pre-release? Even for teams that release frequently, there’s often a lot of pressure to fit more work into a given release, bug fixes and feature work alike. Ideally there are guidelines in place that dictate when a late change is allowed – no feature work, only bugs that impact a critical path or some set of key metrics, that sort of thing – but guidelines still require enforcement and approvals (read: humanpower) and teams often struggle to stick to the rules.

All of these challenges combine into the sort of problem that we’re all about solving here at Runway, at the intersection of tooling and humans, automation and coordination. Runway’s newest feature, Fixes, helps mobile teams better manage and protect their release diffs by applying real guardrails around late-arriving changes. Now, teams have a consistent way to escalate and review late-arriving work, and then pull those changes into the release automatically but only if they get OK’d. Read on for more on how Fixes works!

Make it crystal clear when a late change is incoming, and why

Part of the reason late-arriving work can be so insidious is that it often sneaks into a release unannounced. At best someone might flag a pull request with a required fix, but that often disappears into the black hole that is your noisy Slack workspace; at worst (but not at all uncommonly) they’ll just go right ahead and cherry-pick or merge it into the release, unbeknownst to much of the rest of the team. With Fixes, Runway allows your team to capture a piece of late-arriving work as an actual entity that gets surfaced clearly alongside a release. The team can follow the item’s progress, with full context so everyone across engineering, product, and QA can stay on the same page.

‍
You can add a fix from within Runway on a given release’s feature readiness view, either creating it from any item that already appears on the working branch or using an explicit “+ Add a fix” action. Or, take advantage of a new /runway add fix slash command to create a fix on the fly, without leaving Slack.

Wherever you create a fix, you’re prompted to include additional details on the fix and why it’s needed. This context is surfaced alongside the fix and helps your team build a culture of accountability and standards around what kind of work should actually be allowed to enter a release late in the cycle. You might use this space to capture the scope or severity of a showstopping bug the fix is addressing, or some business level justification for why the change needs to make it in.
‍

Add real guardrails with optional approvals and status checks

Making late-arriving work more visible and attaching context that explains why a change absolutely needs to make it into a frozen release diff can be a big first step. But even then, you’re still relying on team members to be on the same page when it comes to expectations around late-arriving work and to adhere to whatever agreed upon processes you have in place to protect a release that’s stabilizing. With Fixes, you can apply actual guardrails by optionally enabling an approval flow that each and every fix must pass through. With the approval flow enabled, new fixes are highlighted as ‘pending approval’ in the release’s feature readiness view. Pending fixes must be reviewed and can be either approved or rejected by certain folks on your team.
‍

To further enforce approvals, you have the option of enabling GitHub status checks that tie into fixes in Runway. If enabled, status checks will appear on any PRs open against the release branch and they will only pass if and when the associated fix in Runway is approved.

Automate your Git wrangling to avoid mistakes and save time — safely

Some readers may already be familiar with Runway’s cherry-pick automation, which previously allowed you to have Runway automatically pull work into a release based on a specified token being present in a target item’s PR title. With Fixes, this automation has both expanded and become more safeguarded.

Now, with the cherry-pick automation enabled, Runway will automatically pull any fixes over into the release — no need to include some token in an associated PR’s title. (Sidenote: if a PR title does include a designated token and a corresponding fix doesn’t yet exist for that work item, Runway can automatically create the fix.) Rather than executing unchecked, the automation is gated on any conditions that would otherwise apply to your fixes. If you have the fix approval flow enabled, Runway will wait for a fix to be approved before automatically pulling it over into the release.

Keep tabs on your team’s hygiene around late-arriving work with fix metrics

In order to improve your team’s practices around late-arriving work and release stabilization, it’s helpful to track things like how often potential fixes are being raised, how often they’re actually pulled in, and how much of a given release’s diff is made up of these late items. Runway collects metrics like these as you work and surfaces them per release, as well as at an app and org level.  

With Fixes, Runway is giving your mobile team a better way to manage your release diffs and increase consistency & confidence around late-arriving changes. By making late inclusions more visible and auditable, and by adding real guardrails that ensure risky changes like these are properly reviewed and approved before they make it into a release, Fixes protects release health and helps your team establish clear standards around this tricky part of the mobile release process. Go ahead and lock down your release branches, and turn your internal fix request guidelines from forgotten lists of easily ignored suggestions to a built-in, structured part of each and every release.    

Get in touch at hello@runway.team with any questions or feedback or, better yet, schedule a live tour of Fixes with our team!