With today’s simultaneous Facebook and Messenger for Android releases, it’s a great time to talk about how we manage mobile releases here at Facebook. Over the past few months, we’ve taken our successful Facebook.com release process, applied a couple of important tweaks, and repurposed it for mobile. This allows us to rapidly improve app performance, add great new features, and increase stability–all while maintaining a high quality bar. Today’s Facebook for Android update came just four weeks since the last version and our goal is to deliver another in a month. We’re now delivering on regular ship cycles for Facebook for iOS, Camera and Messenger as well.
Until recently, our mobile app development was feature-driven. We’d decide on a bundle of features, furiously work on them, test them, and ship. Great updates we had already finished sometimes took longer to get into people’s hands because we often had to wait for additions and tweaks that threw us off schedule. As we started developing more and more for mobile, it became clear we needed a scalable process to manage the increased mobile engineering activity and ship quality updates to users fast. The good news is we already used that process elsewhere at the company.
A familiar process
As my boss Chuck Rossi previously explained, Facebook.com uses a fast and effective process for shipping improvements to users daily. Now we’re taking the lessons we’ve learned from the past five years on desktop web and applying them to mobile.
We now schedule predictable and explicit dates when we cut from mobile feature development to testing, stabilization, and polishing. This allows engineering to move fast, keeps the apps in a shippable state, and generally removes ambiguity about when code will ship. Moving to a date-driven model means that stability and performance updates , or user-ready features,don’t need to wait on another feature to ship.
Mobile is unique
Shipping mobile software is inherently different than shipping web software — the stakes are higher. It’s easier for code to cause an app crash on mobile than bring down an entire site on the web. And with web software you can roll out gradually and make updates before you roll out to the majority of users. With mobile software we don’t have these luxuries. That means we have to hold ourselves to an even higher quality bar.
For instance, we only take targeted fixes after we’ve cut a release. We scrutinize every change closely and have to explicitly approve any changes. My colleague Mike Shaver put it best when he said that we “need a reason to accept, not a reason to reject.” We frequently say no, and if it becomes clear a fix is too risky or a feature isn’t quite ready we back it out or turn it off without a second thought. This keeps quality high and decouples finished updates from unfinished ones.
Updating an app — while easy for most people — can be more disruptive than reloading a webpage. Because of this, we also wanted to balance getting improvements out to people quickly while minimizing disruptions for users. Our 4-8 week release timelines feel like a good trade-off for now.
We also work to reuse code and tests wherever possible. For mobile products, our apps have to work with different hardware, OS versions, platform capabilities, app stores, partner timelines, programming languages, and testing frameworks. To deliver products efficiently against all those constraints, we share code and tests as much as we can. For example, on iOS and Android the messaging experience in the main Facebook app uses the same code as the Facebook Messenger standalone apps on those platforms. That means we can leverage our Messenger development and testing for the main Facebook app and vice versa.
Prioritizing quality
We’ve adopted this new date-driven release process so that people get important stability, speed, and feature improvements as soon as they are ready. This helps us drive toward higher quality — one of our top priorities on mobile.
