Continuous Deployment Practices for Mobile Apps at Facebook

Continuous deployment is the practice of releasing software to production as soon as it is ready, and it has become increasingly popular in the industry. Mobile software historically lagged behind cloud services in update frequency due to factors such as periodic releases, user‑controlled upgrades, and the diversity of Android hardware variants.

From 2012 to 2016, Facebook increased Android release frequency from every eight weeks to weekly. An analysis of seven years of software‑engineering metrics (2009‑2016) shows that higher deployment frequency did not reduce developer productivity or software quality. The improvement stemmed from better automation of mobile app publishing and deployment, which reduced developers' workload.

Key advantages of continuous deployment include smaller, incremental changes that lower deployment risk, faster user feedback, and quicker response to security threats.

1. Mobile App Release Challenges

Update frequency is limited because app stores require review and users can choose when to upgrade.

The entire app must be shipped as a large binary, increasing risk compared to backend services that can deploy individual modules.

Mitigation measures such as hot‑fixes and rollbacks are often unavailable due to platform restrictions.

Users may run different app versions simultaneously, requiring all versions to remain functional.

Supporting many hardware and OS variants (especially Android) multiplies the risk of each deployment.

2. Separating Development and Release Activities

Facebook’s strategy separates software development from release and deployment.

2.1 Development

Developers push changes to the main branch at the same frequency as backend services, making small incremental commits. When a change is deemed deployable, it proceeds to the next stage.

2.2 Release Deployment

Periodically a Release branch is created from main . Android reached weekly releases in 2016 and iOS in 2017. The Release branch undergoes extensive testing, after which it is published to users.

The workflow includes:

Daily internal Dogfood (or Blooding Version ) builds from main . If no blocking issues arise, the build becomes an Alpha released to a small external group via Google Play.

Each Monday a Release branch is created. For the first three days of the week a Beta version is released to roughly three million external users.

If a Beta version reveals a defect, developers fix it on main , verify, and then Cherry‑Pick the fix into the Release branch.

On Thursday the Release branch is frozen; only blocking‑issue fixes may be merged thereafter. Any further changes are delivered as additional Beta builds.

Formal release occurs one week after the Release branch is created: the final frozen Beta is rolled out on the Play Store in staged percentages (20 %, 50 %, 100 %) over three days, with stability checks after each batch.

3. Release Engineering Team

The release engineering team, though small (fewer than ten members in 2016), plays a critical role. Its size is kept low thanks to highly automated tools and a strong partnership with development teams. Senior product engineers rotate into the release team every two months, spreading knowledge and occasionally building automation tools that further streamline the release process.

Data from the seven‑year study confirms that this model maintains developer productivity and software quality while enabling rapid, reliable mobile releases.

Reference : Continuous Deployment of Mobile Software at Facebook, November 13, 2016.