BT

Facebook’s Release Process Behind the Move from Web-based to Native App

by Manuel Pais on Dec 28, 2013 |

Chaitanya Mishra, from Facebook, spoke at Velocity Conf London last month about the approach to scale Facebook’s Android app from a web view interface to a full-fledged native app. To achieve this transition each product team took ownership of their features on Android. A core integration team regression tests and focuses on global app optimization over individual features optimization in order for the distributed development model to work.

Because shipping new app versions (and fixes) to users depends first on an external party approval and then on the users’ initiative to upgrade, the continuous delivery model used for Facebook’s web development (the site ships twice a day) needed to be adapted to keep a fast cycle time for Android development. Immediate feedback to developers when a build breaks, dog fooding new releases (shipped internally to employees 4 weeks before shipping to the app store) and production-like monitoring (providing quick feedback to dev on functional errors and performance problems) help increase confidence in the releases before they get delivered externally. During that 4 weeks period fixing takes place in a release branch parallel to the master branch (where new features are continuously added and tested for later release).

Besides functional and performance testing (via the UI using Selendroid), other Android specific checks in the build process include app size (are changes unwittingly increasing the app size), memory usage and power consumption (down to actual battery usage). Chaitanya gave the example of a significant and hard to explain power usage increase which turned out to be due to a minor change with a polling mechanism which prevented the app from going to sleep mode.

After shipping to the outside world, app performance and error monitoring is done using Analytics Logger. Feedback data is analysed regularly using an in-house tool called Scuba. Chaitanya mentioned an example when an increasing number of DB crashes was found. Suspecting of low available space on users’ devices, the team added free space measurements only to discover it was actually the app which was consuming a lot more space than needed due to over allocation or even entire copies of database, large caches and also some unnecessary files. After the fixes the rate of DB crashes diminished considerably.

Despite the success in transitioning to a fully native app, Chaitanya conceded that the swing towards native probably went too far occasionally, in particular for less used features that could have remained purely web based. According to Chaitanya the drawback of relying on web is the need to maintain a backwards compatible web site API as much as possible. 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT