ContinuousDeploymentofMobileSoftwareatFacebook资源-CSDN文库

需积分: 10 198 浏览量 2017-12-10 10:40:14 上传评论收藏 2.17MB PDF 举报

资源推荐

资源详情

资源评论

Continuous Deployment of Mobile Software at Facebook

(Showcase)

Chuck Rossi

Facebook Inc.

1 Hacker Way

Menlo Park, CA USA 94025

chuckr@fb.com

Elisa Shibley

University of Michigan

2260 Hayward Street

Ann Arbor, MI USA 48109

eshibley@umich.edu

Shi Su

Carnegie Mellon University

PO Box 1

Moffett Field, CA USA 94035

shis@andrew.cmu.edu

Kent Beck

Facebook Inc.

1 Hacker Way

Menlo Park, CA USA 94025

kbeck@fb.com

Tony Savor

Facebook Inc.

1 Hacker Way

Menlo Park, CA USA 94025

tsavor@fb.com

Michael Stumm

University of Toronto

10 Kings College Rd

Toronto, Canada M8X 2A6

stumm@eecg.toronto.edu

ABSTRACT

Continuous deployment is the practice of releasing software

updates to production as soon as it is ready, which is receiv-

ing increased adoption in industry. The frequency of updates

of mobile software has traditionally lagged the state of prac-

tice for cloud-based services for a number of reasons. Mobile

versions can only be released periodically. Users can choose

when and if to upgrade, which means that several diﬀerent

releases coexist in production. There are hundreds of An-

droid hardware variants, which increases the risk of having

errors in the software being deployed.

Facebook has made signiﬁcant progress in increasing the

frequency of its mobile deployments. Over a period of 4

years, the Android release has gone from a deployment ev-

ery 8 weeks to a deployment every week. In this paper, we

describe in detail the mobile deployment process at FB. We

present our ﬁndings from an extensive analysis of software

engineering metrics based on data collected over a period of

7 years. A key ﬁnding is that the frequency of deployment

does not directly aﬀect developer productivity or software

quality. We argue that this ﬁnding is due to the fact that

increasing the frequency of continuous deployment forces im-

proved release and deployment automation, which in turn re-

duces developer workload. Additionally, the data we present

shows that dog-fooding and obtaining feedback from alpha

and beta customers is critical to maintaining release quality.

CCS Concepts

•Software and its engineering → Agile software de-

velopment; Software conﬁguration management and ver-

sion control systems; Software implementation planning;

Keywords

Continuous deployment; Software release; Mobile code test-

ing; Agile development; Continuous delivery

1. INTRODUCTION

Continuous deployment is the software engineering practice

of deploying many small incremental software updates into

production as soon as the updates are ready [1]. Continu-

ous deployment is becoming increasingly widespread in the

industry [2, 3, 4, 5, 6] and has numerous perceived advan-

tages including (i) lower risk because of smaller, more in-

cremental changes, (ii) more rapid feedback from end users,

and (iii) improved ability to respond more quickly to threats

such as security vulnerabilities.

In a previous paper, we described the continuous deploy-

ment process for cloud-based software; i.e., Web frontend

and server-side SAAS software, at Facebook and another

company

[1]. We presented both its implementation and

our experiences operating with it. At Facebook each de-

ployed software update involved, on average, 92 Lines of

Code (LoC) that were added or modiﬁed, and each devel-

oper pushed 3.5 software updates into production per week

on average. Given the size of Facebook’s engineering team,

this resulted in 1,000’s of deployments into production each

day.

At both companies discussed in [1], the developers were

fully responsible for all aspects of their software updates. In

particular, they were responsible for testing their own code,

as there was (by design!) no separate testing team. The

only requirement was peer code reviews on all code before

it was pushed. However, there was considerable automated

support for testing and quality control. As soon as a devel-

oper believed her software was ready, she would release the

code and deploy it into production.

As demonstrated in the previous paper, cloud-based soft-

ware environments allow for many small incremental deploy-

ments in part because the deployments do not inconvenience

end-users — in fact, end users typically do not notice them.

Moreover, the environments support a number of features to

OANDA Corp.

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for proﬁt or commercial advantage and that copies bear this notice and the full citation

on the ﬁrst page. Copyrights for components of this work owned by others than ACM

must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,

to post on servers or to redistribute to lists, requires prior speciﬁc permission and/or a

fee. Request permissions from Permissions@acm.org.

FSE’16, November 13–18, 2016, Seattle, WA, USA

ACM. 978-1-4503-4218-6/16/11...$15.00

http://dx.doi.org/10.1145/2950290.2994157

manage the risk of potentially deploying erroneous software,

including blue-green deployments [7], feature ﬂags, and dark

launches [8]. As a worst case, stop-gap measure, it is always

possible to “roll back” any recently deployed update at the

push of a button, eﬀectively undoing the deployment of the

target software module by restoring the module back to its

previous version.

In contrast with previous work, in this paper, we describe

and analyze how continuous deployment is applied to mobile

software at Facebook (FB). FB’s mobile software is used

by over a billion people each day. The key challenge in

deploying mobile software is that it is not possible to deploy

the software continuously in the same manner as for cloud-

based services, due the following reasons:

1. The frequency of software updates may be limited be-

cause (i) software updates on mobile platforms are not

entirely transparent to the end-user, and (ii) the time

needed for app reviews to take place by the platform

owner; e.g., Apple reviews for iOS apps.

2. Software cannot be deployed in increments one module

at a time; rather all of the software has to be deployed

as one large binary; this increases risk.

3. Risk mitigation actions are more limited; for example,

hot-ﬁxes and roll-backs are largely unacceptable and

can be applied only in the rarest of circumstances as

they involve the cooperation of the distributor of the

software (e.g., Apple).

4. The end user can choose when to upgrade the mobile

software (if at all), which implies that diﬀerent ver-

sions of the software run at the same time and need to

continue functioning correctly.

5. Many hardware variants — especially for Android —

and multiple OS variants need to be supported simul-

taneously. The risk of each deployment is increased

signiﬁcantly because of the size of the Cartesian prod-

uct: app version × (OS type & version) × hardware

platform.

Given the above constraints, a compelling open question

that arises is: How close to “continuous” can one update

and deploy mobile software?

Facebook is striving to push the envelope to get as close as

possible to continuous deployment of mobile software. The

key strategy is to decouple software development and re-

leases from actual deployment; the former occurs frequently

in small increments, while the latter occurs only periodically.

In particular, developers push their mobile software updates

into a Master branch at the same frequency as with cloud

software and in similarly-sized increments. The developers

do this whenever they believe their software is ready for de-

ployment. Then, periodically, a Release branch is cut from

the Master branch — once a week for Android and once ev-

ery two weeks for iOS. The code in that branch is tested

extensively, ﬁxed where necessary, and then deployed to the

general public. The full process used at FB is described in

detail in §2.

An important follow-on question is: How does this mobile

software deployment process aﬀect development productivity

and software quality compared to the productivity and qual-

ity achieved with the more continuous cloud software deploy-

ment process?

We address this question in §5.2 where we show that pro-

ductivity, when measured either in terms of LoC modiﬁed

or added, or in terms of the number of commits per day, is

comparable with what it is for software as a whole at FB.

We show that mobile software development productivity re-

mains constant even as the size of the mobile engineering

team grows by a factor of 15X and even as the software

matures and becomes more complex. In fact, we show how

Android has gone from a deployment every 8 weeks to one

every week over a period of 4 years, with no noticeable eﬀect

on programmer productivity.

Testing is particularly important for mobile apps given the

limited options available for taking remedial actions when

critical issues arise post-deployment (in contrast to the op-

tions available for cloud-based software). We describe many

of the testing tools and processes used at FB for mobile code

in §4. We show in §5.5 that the quality of FB mobile soft-

ware is better than what it is on average for all FB-wide

deployed software. And we show that the quality of the

mobile software code does not worsen as (i) the size of the

mobile software development team grows by a factor of 15,

(ii) the mobile product becomes more mature and complex,

and (iii) the release cycle is decreased. In fact, some of the

metrics show that the quality improves over time.

Finally, we present additional ﬁndings from our analysis

in §5. For example, we show that software updates pushed

on the day of a Release branch cut are of lower quality on

average. We also show that the higher the number of devel-

opers working on the same code ﬁle, the lower the software

quality.

A signiﬁcant aspect of our study is that the data we base

our analysis on is extensive (§3). The data we analyzed cov-

ers the period from January, 2009 to May, 2016. It includes

all of the commit logs from revision control systems, all app

crashes that were captured, all issues reported by FB staﬀ

and customers, and all issues identiﬁed as critical during the

release process.

The data prior to 2012 is noisier and less useful to draw

meaningful conclusions from. Those were the early days

of mobile software, and there were relatively few mobile-

speciﬁc developers working on the code base. In 2012, FB’s

CEO announced the company’s “Mobile First!” strategy to

the public at the TechCrunch Disrupt conference in San

Francisco. From that point on, the mobile development

team grew signiﬁcantly, and the data collected became more

robust and meaningful. Hence, most of the data we present

is for that period of time.

In summary, this paper makes the following speciﬁc con-

tributions:

1. We are, to the best of our knowledge, the ﬁrst to de-

scribe a process by which mobile software can be de-

ployed in as continuous a fashion as possible. Speciﬁ-

cally, we describe the process used at FB.

2. This is the ﬁrst time FB’s testing strategy for mobile

code is described and evaluated.

3. We present a full analysis with respect to productiv-

ity and software quality based on data collected over

a 7 year period as it relates to mobile software. In

particular, we are able to show that fast release cy-

cles do not negatively aﬀect developer productivity or

software quality.

剩余11页未读，继续阅读

评论收藏

内容反馈

test4ever

粉丝: 2
资源: 8

Continuous Deployment of Mobile Software at Facebook

基于Facebook的Hive开发

facebook 开发操作

Continuous.Integration.Delivery.and.Deployment.epub

Continuous Deployment with Gerrit and Jenkins

Learning Continuous Integration with Jenkins, 2nd(2017).epub

毕业设计：基于ASP.NET的Continuous deployment系统.zip

Continuous Delivery & Continuous Integration

Deployment with Docker: Apply continuous integration models, deploy applications

Infrastructure for Automatic Dynamic Deployment Of J2EE Application in Distributed Environments.pdf

源码Deployment with Docker_ Apply continuous integration models, deploy app

software processes and Life Cycle Models

Fast Database Restarts at Facebook

Database design & Database deployment software BDB 2007 Professional V2.3

Database design & Database deployment software BDB 2007 Developer V2.3

Continuous Delivery - Reliable Software Releases Through Build,

Deployment of Deep Learning Models on Smartphones as Real-Time APP

Software.Testing.Concepts.and.Operations.1118662873.epub

Quantization for rapid deployment of deep neural networks

带低光照补偿的yolov8检测分割模型（The deployment of Yolov8-seg on Jetson AGX ）

Coverage Enhancement for Deployment of Multi-camera Networks

Building.Software.Teams.epub

Docker on Windows

Mobile Developer Economics 2010 Report+FINAL

最新资源