摘要
持續部署是指軟體更新一旦準備好就立即釋出的實踐方法，在業界越來越多地被採用。移動端軟體的更新頻率普遍落後於基於雲端的服務，原因有很多。比如，移動端軟體只能定期釋出版本；使用者可以選擇何時升級以及是否升級，這意味著多個不同的版本需要在生產環境中共存；Android裝置多種多樣，增加了在部署軟體時出錯的風險。
Facebook在提升移動端軟體部署頻率方面取得了重大進展，在4年的時間裡，Android版本從每8周釋出一次變成了每1周釋出一次。本文中，我們詳細描述了Facebook移動端軟體的部署過程。我們基於7年時間內蒐集的資料，對軟體工程指標進行廣泛分析，提出我們的研究結果。一個關鍵的發現是，部署的頻率並不直接影響開發人員的生產效率或軟體品質。我們認為這個發現是由於增加持續部署的頻率可以促進發布和部署的自動化，從而減少開發人員的工作量導致的。此外，我們提供的資料表明，從Alpha版本和Beta版本的試用客戶那裡獲得反饋對於保持釋出品質至關重要。
軟體工程/敏捷軟體開發軟體配置管理和版本控制系統軟體實施計劃本著作全部或部分的電子版或硬拷貝可用於個人或課堂使用，但不收取任何費用，前提是拷貝不是為了利潤或商業利益而製作或分發，且拷貝在第一頁上印有本通知的完整的引文。必須尊重除ACM以外的其他人擁有的本作品的權利。允許被授權的摘錄。以其他方式複製、再發行、在伺服器上釋出或重新發布到列表，需要事先獲得特定的許可和/或支付費用。
關鍵詞持續部署；軟體釋出；移動端程式碼測試；敏捷開發；持續交付
一、介紹
持續部署是一種將軟體增量在準備就緒後就更新到生產環境中的工程實踐。持續部署在業界正變得越來越普遍，並具有諸多優勢，包括更小的增量式變更帶來的低風險，更多來自終端使用者的快速反饋，以及對安全漏洞等威脅的更快速的響應能力。
在提到的兩家公司中，開發人員對軟體更新完全負責，他們沒有（就是這麼設計的！）單獨的測試團隊，開發人員負責測試自己的程式碼，只是在程式碼提交之前需要進行同行評審。但是，對於測試和品質有大量的自動化支援，只要開發人員認為軟體已經準備就緒，就可以把釋出程式碼並將其部署到生產環境中。
正如在前一篇文章中演示的，基於雲端的軟體環境允許眾多小的增量部署，部分原因是部署不會給終端使用者帶來不便。此外，環境支援很多特性以管理可能導致部署錯誤的風險，包括藍綠部署、功能釋出開關和灰度釋出。即使最壞的情況，只需要按下一個按鈕，就可以“回滾”到任何最近部署的更新，將模組恢復到以前的版本。
與之前相比，在本文中我們描述並分析了持續部署如何應用於Facebook的移動端軟體。Facebook移動端軟體每天超過10億人使用，軟體部署的關鍵挑戰在於不可能像基於雲的服務那樣進行持續部署，原因如下：
軟體更新的頻率可能是有限的，因為移動平臺上的軟體更新對終端使用者來說不完全透明，平臺的應用稽核也需要時間。例如，蘋果對iOS應用的稽核。軟體不能按照模組部署。只能作為一個整體進行部署，這會增加部署的風險。降低風險的措施有限。例如熱修復和回滾在很大程度上是不可接受的，只能在極端情況下使用，因為涉及到與釋出平臺的協作（如蘋果）。終端使用者可以選擇何時升級（如果允許的話），這意味著不同版本的軟體在同時執行時要能夠正常工作。不同的硬體種類（特別是Android平臺），以及需要支援多個不同版本的作業系統。笛卡爾乘積：應用的版本數量作業系統型別和版本硬體平臺數量，導致每次部署的風險都大大增加。考慮到上述限制，一個有力的開放式問題出現了: 如何能夠“持續”進行移動端軟體的部署。
Facebook正在努力挑戰極限，儘可能接近移動端軟體的持續部署。關鍵的策略是將軟體開發、釋出與實際的部署解耦：前者經常以小型增量出現，而後者只是週期性出現。特別是開發人員將移動端軟體以和雲端軟體相同的頻率進行更新，以類似大小的增量提交到Master分支。只要開發人員認為他們的軟體已經可以部署，他們就會這樣做。然後，定期從Master分支中切分出一個釋出分支，對於Android是每週一次，對於iOS則是兩週一次。這個分支中的程式碼經過了大量的測試，並進行必要的修復後向公眾釋出。在Facebook中應用的完整流程在第2節中詳細描述。
接下來的一個重要問題是：與更連續的雲端軟體部署過程相比，移動端軟體部署過程如何影響開發生產效率和軟體品質?
在5.2節中，我們展示了無論以修改或增加的程式碼行，還是以每天提交次數為度量指標的生產效率，都與Facebook相當。即使移動端工程師團隊增長了15倍，甚至軟體隨著功能增加變得更加複雜，移動端軟體開發生產效率仍然保持不變。事實上，在4年時間裡，Android端從每8周部署一次到每1周部署一次，對程式設計師的工作效率沒有明顯的影響。
測試對移動端應用尤其重要，因為在部署後出現關鍵問題時，可供採取的補救措施有限(與基於雲端的軟體相比)。我們在第4節中描述了許多在Facebook中用於移動端程式碼的測試工具和流程。我們在5.5節中展示了Facebook移動端軟體的品質要高於Facebook中所有軟體的平均品質。我們發現，移動端軟體程式碼的品質並沒有隨著開發團隊的規模增長、產品的成熟和複雜、釋出週期的縮短而惡化。事實上，一些度量指標表明品質會隨著時間的推移而提高。
最後，我們在第5節展示了經過分析的調查結果。例如，我們提出在釋出分支被切分出來的當天，軟體更新的平均品質較低。我們還表明，在同一程式碼檔案上工作的開發人員的數量越多，軟體品質就越低。
我們研究的一個重要方面是，我們的分析基於大量的資料 (第3節)。從2009年1月至2016年5月，包括來自版本控制系統的所有提交日誌、所有應用程式崩潰記錄、Facebook員工和客戶報告的所有問題以及釋出過程中確定的所有關鍵問題。在2012年以前的資料中，有意義的結論相對較少，因為那時處於移動端軟體的早期階段，專門從事移動端軟體開發的人員相對較少。2012年，Facebook執行長在舊金山的TechCrunch Disrupt大會上向公眾宣佈了公司的“移動端優先”戰略。從那時起，移動端開發團隊顯著增長，收集的資料變得更加完整和有意義。因此，我們提供的大部分資料都是針那段時間的。
綜上所述，本文的具體貢獻如下:
據我們所知，我們第一個描述了移動端軟體的持續部署流程。具體來說，是指Facebook的移動端軟體持續部署流程。這是首次對Facebook的移動端軟體測試策略進行描述和評估。我們基於7年間蒐集的與移動端軟體相關的資料，對生產效率和軟體品質進行了全面分析。我們能夠證明快速的釋出週期不會對開發人員的生產效率或軟體品質產生負面影響。我們相信我們第一個提出了以下兩個引人注目的發現：
(i) 修改同一個程式碼檔案的開發人員數量與該程式碼檔案對應的軟體品質成反比；(ii) 在從Master分支中切分出釋出分支的當天提交的程式碼品質，要低於其他日期提交的程式碼品質。在下一節中，我們將介紹Facebook中Android和iOS端軟體的釋出週期。第3節展示我們蒐集的用於分析的資料。第4節描述使用的測試策略。在第5節中我們提供分析結果。在第6節介紹其他相關的工作。最後，我們會用一篇結束語來結束。
二、移動應用的釋出週期
在本節中，我們將詳細描述Facebook針對移動應用開發部署的流程和活動。整體架構如圖1所示。有兩類活動：開發活動和部署活動。
2.1 開發活動首先，我們描述一下開發活動。在Facebook，移動端軟體和基於雲端的軟體開發活動實際上沒有區別。開發人員從主分支拉出一個local revision control system分支。開發時基於本地分支頻繁提交。在經過適當的測試後，當開發人員認為軟體更新已經準備好可以部署時，將更新的程式碼提交到主分支。正如我們在§5中所展示的，每個開發人員每週會向主分支提交3-5次，這個頻率與Facebook基於雲端的軟體等同。
2.2 部署活動現在，我們描述一下圖1的下半部分，部署活動。Facebook有一個釋出工程團隊(RelEng)負責這些活動。團隊中包括負責對應平臺的專案經理，他們會對阻塞問題做出判斷。
iOS和Android都是以流水線的方式做週期性部署，每個週期天數相同。我們首先描述iOS的具體流程，然後再描述Android的流程的不同之處。
圖1：iOS釋出週期
整個兩週的過程中，每個階段都是在流水線中(iOS移動程式碼)：基於釋出分支的穩定性測試、效能測試、程式碼評審和部署需要兩週時間，而在這兩週裡，新的軟體程式碼會不斷被提交到主分支，直到從主分支中拉出下一個釋出分支。
對於iOS來說，釋出工程團隊會以兩週為週期，在第二個週日的下午6點，從Master分支中拉出一個Release分支。Release分支首先要穩定執行5天，在此期間對問題進行修復，並做一些優化和穩定性方面的更新。那些被髮布工程團隊歸類為影響終端使用者使用的阻塞性Bug必須在部署之前修復。最後，釋出工程團隊可以通過將部分程式碼恢復到以前的版本來繞過一些問題。
開發人員負責解決釋出工程團隊提出的任何問題，比如已確定的bug。開發人員在解決問題所做的任何更新（包括Bug修復、優化和穩定性更新），都需要提交合併到Master分支。然後，開發人員必須請求釋出工程團隊將主分支的更新合併到釋出分支中，並解釋為什麼需要合併。
接下來，釋出工程團隊根據自身判斷，將更新的程式碼合併到Release分支。他們會考慮各種風險因素進行謹慎的分析判斷，合併程式碼的請求可能因為各種原因被髮布工程團隊拒絕。舉兩個因為合併風險過高而被拒絕的例子：有太多依賴（比如超過5個）的更新和對核心元件（如網路和顯示）做出重大更改的更新。最終，釋出工程團隊會權衡風險和影響做出判斷。例如，一個影響較小的優化類更新，在前2-3天是可以接受的，之後就會被拒絕合併。
在上述的穩定階段，通過Release分支構建的App會像“狗糧”一樣提供給Facebook內部使用者使用，每天會提供三次。經過5天的穩定期，程式碼會被凍結，開始進行為期3天的效能測試。在效能測試期間，只接受阻塞性問題的修復。
最後，在建立Release分支後的第二個週一，會提交軟體到蘋果公司稽核，並在那周的晚些時候釋出。
在整個過程中，如圖1所示，在當前Release分支穩定的同時，新的更新程式碼被提交到Master分支。這些更新只有一部分會被髮布工程團隊合併到Release分支中。不論出於什麼原因，如果圖右半部分所示的兩週不能安全的完成，就會停止部署，所有的程式碼更新都會被推遲到下一次的定期部署。
Android的釋出週期和iOS基本一樣，只是拉Release分支的週期由2周被壓縮至1周。週四凍結程式碼，只接受阻塞性問題的修改。
在週一早晨（拉出Release分支後的那周），App通過應用商店分批逐步分發給使用者，通常是在接下來的三天內，分別推送20%、50%和100%的使用者。每增加一次推送使用者比例，都需要定期進行穩定性檢查。
對於Android來說，Facebook也會發布Alpha和Bate測試版App。Alpha版本每天從Master分支構建，通過Google Play Store分發給一小部分外部使用者（通常小於10000使用者）。Bate版本每天從Release分支構建，並提供給更多的外部使用者（大約300萬）。
釋出工程團隊釋出工程團隊在上述過程中扮演著關鍵的角色。儘管它很重要，這個團隊可能比人們想象中要小——只有不到10個成員。
高級別的產品開發人員不斷被借調到釋出工程團隊臨時工作，每次大約2個月時間。這種安排的一個核心優勢是，在釋出工程團隊和開發團隊間建立了合作伙伴關係。開發人員開始了解釋出工程團隊在做什麼，流程是什麼，有哪些問題和痛點等等。開發人員在釋出工程團隊工作期間積累的知識，會在回到團隊後傳授給其他成員。
這種安排的另一個好處是，開發人員在發現釋出過程效率低下之後，在某些情況下會為釋出工程團隊開發工具，從而使釋出過程進一步簡化和自動化。
三、資料蒐集
Facebook收集與每個版本和每個部署相關的大量資料。它保留所有這些資料。在本節中，我們將描述在§5中用於分析的資料集。
3.1 修訂控制系統記錄該資料集記錄了每次提交和推送、日期、要提交的差異的大小（以LoC度量）、釋出差異的開發人員等。
3.2 崩潰（Crash）資料庫FB應用程式崩潰時，崩潰報告會自動傳送到FB。崩潰率是應用程式品質的直接指標，這就是為什麼要仔細監控這些崩潰報告並用來確定發行版本的執行狀況的原因。機器人（Bots）程式會自動將可靠性問題分類為崩潰、軟錯誤、掛起的系統等。每當給定的崩潰率指標高於指定的閾值時，崩潰就會作為啟動阻止程式自動提交給任務資料庫（如下所述 ）。
此外，會自動將崩潰的應用程式的堆疊跟蹤與版本控制系統中記錄的最新更改進行比較，如果堆疊跟蹤上的任何指令接近已更改的程式碼，則將以自動方式通知進行更改的開發人員辦法。我們按日期和應用程式版本彙總崩潰報告。
3.3 捕蠅器（Flytrap）資料庫該資料庫包含（內部或外部）使用者提交的問題報告。使用者可以從應用程式上的“報告問題”元件提交問題，該問題可以從下拉選單或通過搖動裝置獲得。或者，他們可以在FB網站上填寫幫助中心“聯絡表”。員工生成的捕蠅器會自動輸入到任務資料庫中（如下所述）。使用者生成的捕蠅器不會自動輸入到任務資料庫中，因為許多使用者提交了不重要的問題、新功能請求、各種改進建議，有時只是垃圾。
總體而言，Flytrap資料庫非常嘈雜。因此，只有當機器人能夠識別足夠數量的使用者超過給定閾值報告的問題時，使用者生成的捕蠅器才會自動輸入到任務資料庫中。我們按日期和應用程式版本彙總了Flytrap問題。
3.4 任務（Task）資料庫該資料庫是釋出工程管理系統的核心元件。它記錄了將要執行的每個任務以及需要解決的每個問題。任務由人類和機器人輸入；機器人建立的任務數量正在迅速增加。與移動版本相關的任務包括：
阻礙啟動（launch-blocking）問題以RelEng標記的關鍵問題，需要在部署之前解決。崩潰機器人（crashbot）問題：當崩潰影響超過閾值數量的使用者時，bot所建立的任務。捕蠅器（flytrap）問題：由漫遊器為員工報告的問題建立的任務，以及超過閾值數量的捕蠅器報告識別出同一問題的任務。測試失敗：為失敗的自動測試建立的任務（請參見第4節）。3.5 精選（Cherry-pick）資料庫記錄所有精選請求，並標記RelEng接受的請求。我們使用“精選點”的數量作為軟體品質的代理指標。
3.6 生產問題資料庫生產程式碼中標識的所有錯誤都記錄在一個單獨的資料庫中，並且每個錯誤都按照嚴重性進行分類：嚴重、中優先順序和低優先順序。當人們認為需要修復生產錯誤（即使優先順序較低）時，記錄的錯誤就會被人輸入。我們使用該資料庫中的問題數量作為部署到生產中的軟體品質的一種度量。
3.7 日活人數（DAP）該資料庫記錄使用FB應用程式的使用者數。我們按資料和應用程式版本彙總了數字。在某些情況下，我們使用此資料來規範崩潰和捕蠅器品質指標。
3.8 鍋爐房該資料庫包含有關每個移動部署的資訊，包括部署日期、部署狀態、從中進行構建的版本分支、所部署的版本的截止日期、alpha / beta /生產版本等。
3.9 員工資料庫該資料可確定每天有多少開發人員在做移動軟體開發。該資訊是從提交的日誌中提取的：如果開發人員在前兩週提交了移動程式碼，則認為她一直在從事移動軟體的開發。
3.10 原始碼和配置程式碼我們使用來自該來源的資訊來確定自動化作業的計劃方式和時間、以及機器人用來確定何時建立任務的閾值等。
四、測試
測試對於移動應用來說尤其重要，原因如下：
每週對移動軟體進行成千上萬次更新； 必須進行數百種裝置和操作版本組合；在部署後出現嚴重問題時可採取的補救措施很有限。正如人們可能期望的那樣，FB應用了多種型別的測試，包括單元測試、靜態分析測試、整合測試、屏幕布局測試、效能測試、構建測試以及手動測試。
工具和自動化起著關鍵的作用，數百名工具開發人員給我們提供了支援。大多數測試以自動化方式執行。當檢測到迴歸時，會嘗試將其自動繫結到最近進行的特定程式碼更改，然後自動將電子郵件傳送給負責該特定更改的開發人員。
在我們描述一些測試之前以及何時進行測試，簡要介紹了可用的測試基礎架構FB以及指導FB測試的原則策略。
4.1 測試基礎架構數千個計算節點專用於測試移動軟體。通過在模擬和模擬環境中執行測試，可以應用白盒和黑盒測試策略。
為了在真實硬體上進行測試，FB執行著真實的移動裝置。位置在Prineville資料中心的實驗室[9]。移動實驗室主要用於測試效能下降，主要關注應用速度，記憶體使用情況和電池效率。
移動實驗室包含電磁隔離的機架。每個機架放置多個測試裝置iOS 和Android。節點將安裝、測試和解除安裝目標軟體。Chef，是一種配置管理工具[10]，用於配置-裝置。機架中的無線接入點支援裝置Wi-Fi通訊。裝置放置在機架上，以便它們的螢幕可以被攝像機捕獲。工程師可以遠端訪問攝像機以觀察每個裝置都會對程式碼更改做出反應。因此，實驗室有效提供測試基礎架構即服務。
4.2 Testing Principles at FBFB的測試原理FB的測試策略包括以下原則：
測試範圍。測試範圍儘可能的全面，所有已編寫還在執行的都應該測試。儘可能合理地開展測試工作。快速響應。捕獲迴歸的速度越快，處理起來就越容易；快速捕獲的問題更容易被開發人員解決，因為程式碼和程式碼結構仍然是最重要的。例如，使用並行構建以便能夠更快地提供反饋。目標是能夠在開發完成後10分鐘內向其提供冒煙測試的結果。品質。測試應辨認出首要問題。精確，誤報和錯報需要被最小化。這很重要，不僅能最大程度地減少開發人員花費在追蹤錯誤警報上的時間，並且還能防止測試時間超時。自動化。測試儘可能地自動化。這使得它們可重複使用，並確保測試能夠定期執行。自動化的另一個方面已經被證明是有用的: 自動識別導致程式碼變更的開發人員，以便他能夠立即被告知關於檢測到的問題和可能導致問題的程式碼的具體細節。這是通過比較程式碼中可能導致檢測到的問題的位置與最近應用的程式碼更改來實現的。由於這種能力只有在品質高的時候才有效，因此人們已經投入了大量的精力來發展這種能力。優先次序。測試需要大量的計算資源，如果它是詳盡的，並在同一時間響應。由於資源總是有限，一個優化過的測試策略是必須的。例如，當一個更改被推送到主分支時，整合測試只在應用程式中那些可能被推送的更改影響的部分進行，而不是執行整個測試套件。這使得更快地向開發人員提供關鍵測試結果成為可能。完整的整合測試每隔幾個小時在主分支和釋出分支上執行一次。表1: 對移動軟體進行的測試範圍
測試，當他們執行表1列出了一些型別的測試進行了移動軟體。這些測試在開發和部署週期的所有階段執行。1）預推試驗開發人員在開發程式碼時，經常會在自己的 pc / 膝上型電腦上執行單元測試。考慮到應用程式的規模以及 pc 和膝上型電腦的開發能力有限，更廣泛的單元測試將在模擬環境中的伺服器上執行。開發人員還可以手動呼叫表中列出的任何其他測試，最常呼叫的是靜態分析和一些整合測試。最後，還有一點，雖然沒有單獨的測試團隊，但在將任何程式碼推送到主分支之前，都需要對程式碼進行審查。
2）推送當開發人員認為他的更改已經完成並且工作正常時，他開始將他的更改推送到 master 分支。在實際的推送發生之前，會自動執行許多測試，以確定是否應該阻塞推送。這些測試包括標準的單元測試以及一些冒煙測試，這些測試可以驗證大量使用的特性及其關鍵流是否正常工作。此外，還執行測試以確保帶有更改的構建能夠正確工作。但是，由於完整的構建需要大量的時間和資源，這裡的構建測試只測試幾個級別的依賴性。
如果所有測試都通過，則將更改推送到主分支。合併過程可能會識別衝突，在這種情況下，會通知開發人員，以便他能夠處理衝突。
在Master和Release分支上進行連續測試。所有測試都在Master和Release分支上連續執行（每隔幾個小時）。其中最重要的是移動裝置實驗室中的完整構建測試、整合迴歸測試和效能測試。
正如在2中提到的，Alpha 版本是從 master 分支構建的(ios 每天兩次，android 每天一次) ，beta 版本是從 release 分支構建的，每天三次。如果某個百分比的測試失敗，Alpha 版軟體的釋出就會被阻止。這種情況很少發生。
3）人工試驗一個約有100人的手工測試小組用來測試移動應用程式。他們做了各種冒煙測試和邊緣情況測試，以確保應用程式按預期執行。測試團隊主要用於測試尚未建立自動化測試的新特性。最後，在添加了語言翻譯之後，他們負責 UI測試，以評估外觀和品質。
五、分析
5.1 方法
我們對臉書移動軟體工程的定量分析是基於$3的資料描述。從這些資料集中提取的資料被清洗、解釋、交叉檢查，得出的結論被提交給臉書內部的主題專家進行確認。我們描述了資料集是如何在相關的圖示題中被清理的。
一些資料集是從 2009 年 1 月開始的。一直持續到 2016 年。2009 年至 2012 年期間收集的指標相當嘈雜，以至於很難推斷出有用的見解。本節的前幾張圖描述的是 2009 年以後的資料，後面幾張圖描述的是 2012 年到 2016 年的資料。在 2012 年，開發移動端程式碼的開發人員不足 100 人，而到 2016 年，開發移動端程式碼的開發人員已超過 1500 人。每天有超過十億的使用者使用這個軟體。
圖2：每個開發人員每天平均推送的程式碼行數。插入圖顯示了 2012 年中期以後的相同資料。(來自機器的推送被從資料集中刪除，為了避免包含第三方軟體包、移動或刪除目錄而修改了 2000 多行程式碼的推送也是如此。)
5.2 開發人員的生產力圖2描述了開發人員的生產力，這是通過程式碼行(LOC)來度量的，最終平均每個開發人員和每天推送和部署程式碼行。該圖顯示，對於Android和iOS，開發人員平均每天生成70個LoC。這與全公司範圍內所有軟體中每個開發人員每天產生的 64.5 LoC 是一致的(5)。（後臺服務的程式碼生成速度比平均速度慢。）
圖3描述了Android 和 iOS 每天的平均推送量。在過去兩年中，每個開發者平均每天的推送量分別為 0.7 和 0.8。在全公司範圍內的軟體中，平均每個開發者每天的工作量是 0.7，因此，iOS 的推送更加頻繁。雖然 Android 每天每個開發者的推送量少於 iOS，但它每天每個開發者生成的 LoC 數量與 iOS 相同，這意味著 Android 的推送量略大於 iOS。
比絕對數字更有趣的是，開發人員為移動平臺編寫程式碼的數量是如何隨時間變化的——圖4描述了這些開發人員的數量是如何隨時間變化的:
圖4：Android和iOs開發團隊的規模增長。y軸被故意省略，以免洩露專有資訊。
發現1：即使在程式碼基礎上工作的工程師數量增加了15倍，生產力仍然保持不變。這是Android和iOS開發者的情況，無論是通過LoC推送還是推送的數量來衡量。對於這種情況的一種假設是，更大的開發組和更復雜的程式碼庫所導致的效率低下，可以通過(i)工具和隨時間的推移而進行的自動化改進，以及(ii)所使用的敏捷開發、持續釋出和部署過程來抵消。然而，我們可以得出明確的結論:
發現2：臉書移動軟體的持續部署過程不會對生產效率產生負面影響，即使開發組織的規模顯著擴大。
5.3 品質在臉書，每個需要處理的產品環境程式碼問題都要在產品環境問題資料庫中註冊，並按嚴重程度進行分類：
(i)危急的，“需要立即在高優先順序處理的問題；(ii)中等優先順序處理的問題；(iii)低優先順序處理的問題”。我們使用在生產程式碼中發現的問題的數量作為生產軟體品質的一個保證。
圖5描述了每個嚴重級別的問題數量，作為Android和iOS每月推送量的函式。(紅色)三角形代表關鍵的錯誤，自2012年以來，它們幾乎保持不變，每個版本都有0個或1個關鍵問題。
發現3：無論決策數量多少，由決策產生的關鍵問題的數量幾乎是不變的。我們推測，關鍵問題的數量較少有兩個原因：
首先，在測試中更容易發現關鍵錯誤；
其次，公司非常重視關鍵問題，所以每次發生問題後，都會召開一次常務審查會議，以了解問題的根本原因，並確定在未來的部署中如何避免類似的問題。
不出所料，中優先順序和低優先順序問題的數量與推送量呈線性增長，儘管斜率非常低：對於中優先順序問題，斜率分別為0.0003和0.00026，分別適用於Android和iOS。
圖5：2011年3月至2016年5月期間，Android和iOS產品程式碼的問題記錄數量與每月推送量的函式關係。
最上面的圖表是Android的；iOS的底部。注意，x軸和y軸的比例非常不同：所有的線性趨勢線的斜率都小於0.0012。
對於低優先順序問題，Android和iOS的斜率分別為0.0012和0.00097。中、低優先順序問題的傾斜度在Android上都高於iOS；相對大量的Android硬體平臺可能是一個潛在的解釋。
有趣的是，在整個公司範圍內，所有的軟體，這兩個相應的斜坡分別是0.0061和0.0013，這兩個斜坡都比移動程式碼更陡。
總的來說，我們認為這些資料證明了應用於移動軟體的測試策略是有效的。
圖6顯示了針對Android和iOS的每個部署的啟動阻塞問題的數量和挑選的數量。為了便於直接比較，這些數字是根據釋出週期的長度進行規範化的，這是基於這樣一個假設：一個長兩倍的釋出週期將有兩倍的push和兩倍的LoC修改。也就是說，圖中的每個資料點描述了平均年齡每天記錄的精選和發射阻滯劑的每個釋放週期數。
總的來說，啟動阻滯劑的數量和挑選的數量似乎會隨著時間的推移而有所波動，但沒有特別的趨勢。挑選的數量似乎主要停留在Android的5-25和iOS的5-15之間。
發現4：部署週期的長度不會顯著影響挑選和啟動阻滯劑的相對數量，因為它從4周減少到2周(然後是Android的1周)。由此我們得出結論，使用所描述的持續部署過程，部署週期的長度不會直接影響所生成軟體的品質。特別是，在部署頻率變化的點上，曲線沒有不連續。
圖6：每個Android(頂部)和iOS(底部)部署的啟動阻塞問題的數量(藍色實線)和挑選的數量(橙色虛線)，根據釋出週期的長度進行標準化。
圖中的每個資料點描述了每個釋出週期中每天平均記錄的精選和啟動攔截器的數量。垂直的直線顯示了釋出週期的縮短，先是從4周的節奏減少到2周的節奏，然後是Android的減少到1周的節奏。
我們應該注意到，阻塞啟動的數量受到至少兩方面的影響。
首先，一個問題是否被宣佈為啟動阻塞是主觀的。RelEng認為，隨著時間的推移，他們在決定什麼是啟動阻滯劑方面已經變得更加嚴格。這有點直觀：隨著越來越多的人使用移動應用程式，標準往往會提高。
其次，在2015年和2016年開發了大量的測試工具。這些工具可以提高程式碼品質，從而減少啟動阻塞問題。
圖7顯示了終端使用者每天所經歷的崩潰率，為了隱藏ab溶質值，將其標準化為常數。條形圖的不同顏色代表不同的版本：每減少一次部署週期，色域就會變得更窄(但在節假日期間可能會更寬)。
發現5：縮短髮布週期似乎不影響崩潰率。2015年上半年，安卓系統的崩潰數量有所增加，這有兩個原因。
第一，範圍，什麼被認為是崩潰擴充套件到也包括Java崩潰時執行的FB應用程式和應用程式不再回應。
第二，引入了一套第三方軟體庫，提高了系統的crashrate。今年下半年，一些違規軟體被移除。
Facebook內部員工在幫助通過“吃自己的狗糧”來測試移動軟體方面發揮了關鍵作用。iOS平臺在內部獲得了更好的狗糧覆蓋，因為僱員傾向於iOS(而不是Android)。這是一個相當嚴重的問題，因為Android執行的硬體種類繁多。由於這個原因，Android更多地依賴於其軟體的測試版和測試版。
圖8顯示了alpha版本的有效性。
圖7：Android頂部圖和iOS(底部圖)的標準化日崩潰率：經歷崩潰的終端使用者與被標準化為常數的活動使用者總數的比例。
垂直的直線顯示了釋出週期縮短的地方，首先從4周縮短為2周，然後是Android縮短為1周。為了隱藏絕對值而允許比較，曲線被歸一化為相同的常數。
關於崩潰從alpha到beta的崩潰率明顯下降；在軟體的beta版本中偶爾出現的崩潰率峰值不再出現在軟體的生產版本中。軟體的alpha版本的崩潰率大約比產品版本高10倍。
5.4 最後期限的影響在釋放分支被切斷的那一天，向主分支推送的次數明顯增加。這可能表明開發人員急於在截止日期前提交他們的程式碼，這就引出了一個問題：在釋出日提交的程式碼品質是否下降了?
圖9描述了每一次推送選擇的數量，作為釋出分支被削減當天推送比例的函式。挑選的數量被用作軟體品質的代理。在釋出日所做的推送的百分比和每天所選的櫻桃數量之間存在相關性：隨著釋出日所做的推送的數量的增加，所需要的櫻桃數量也隨之增加。
從絕對意義上講，Android在“剪下日”的推送比例更高。這主要是因為許多資料點表示以一週為週期的釋出，而所有iOS資料點表示以兩週為週期的釋出。也就是說，如果所有的Android推送都均勻地分佈在七天裡，那麼每天會有14%的推送；另一方面，如果iOS推送在14天內均勻分佈，那麼每天的推送量應該佔總推送量的7%。
發現6：在最後期限當天推出的軟體品質較低。我們的假設是，在削減日推出的軟體很可能是匆忙的，匆忙的軟體將有較低的品質。
圖8：Android 臉書應用程式的alpha(頂部圖)、beta(中間圖)和production (bot tom圖)版本的正常每日崩潰率：經歷崩潰的終端使用者與正常為常數的活躍使用者總數的比例。
注意，下面的圖和上面的圖是一樣的：圖7的圖形，只是y軸的比例不同。這些圖顯示了讓使用者測試軟體的alpha和beta版本以提高軟體品質的重要性。
在正常情況下，Android在裁員日的推送比例更低，因此專業人士的選擇比例也更小。對此，一個直觀的解釋是：如果一個開發人員認為他的更新不符合要求，他們只需等待一週，因此不會強制執行。然而，如果下一個削減的幅度更大，那麼一些開發人員寧願強行推進而不是等待更長的時間才能更新部署。
另一個有趣的發現是，將截短日期移到週末可以提高品質，部分原因是當截短日期是週末時，匆忙推送更新的傾向較低。2015年8月安卓和2016年2月iOS的截圖時間從週四改到了週日。而推的平均次數iOS的週末推送量從每天0.3次增加到每天0.5次，Android的週末推送量從每天0.175次增加到每天0.5次(圖中未顯示)，（6）週末推送量仍明顯低於工作日推送量。如圖9所示，推動週末削減日的次數越少，與那些釋出的櫻桃選擇的次數越少相關，這是品質提高的標誌。
5.5 影響軟體品質的因素一個有趣的問題，什麼因素影響軟體品質？上面我們展示了在截止日期推出的軟體將會有較低的品質。但我們也證明了把削減日期改到星期天總體上沒有影響。開發人員的生產力、釋出週期的長度、工程團隊的規模、推的數量似乎不會直接影響軟體品質。我們找到和軟體品質相關的兩個因素：
每個push變化的大小(以修改後的LoC度量) ；正在更改的檔案的大小。圖9：每一次推送的選擇與釋出截止日期的推送比例的函式。
週四的截線顯示為紅色的圓圈；星期天的時候切成三角形。對於Android來說，只能在2014年6月之後釋出——包括在內。也就是發行週期轉變為兩週節奏的時候。對於iOS來說，只有在2014年9月之後的版本才會被包括在內，也就是在那個時候釋出週期才會切換到兩週的節奏。截至2016年5月底的版本同時適用於Android和iOS。
然而，我們確實發現了兩個影響軟體品質的因素，儘管這兩個因素高度相關。首先，我們發現隨著將mit程式碼新增到釋出檔案的開發人員數量的增加，檔案被挑選出來的概率也隨之增加。如圖10所示。
發現7：越多的開發人員參與修改一個版本的檔案，這個檔案的軟體品質就越低。有些檔案的修改量大得驚人。這種情況自然發生的一個示例場景是非常大的switch語句，其中與各個case語句相關的程式碼由不同的開發人員修改。
圖10：n個開發人員修改時選中檔案的比例，n=1..40。
圖11：在n=1.40的情況下提交n次時選中的檔案的比例。
上述發現表明檔案需要修改-由多個開發商可能應該分裂，以改善品質。
我們發現影響軟體品質的第二個因素是一個檔案在剪下之間被推送的次數。推的數量越多，檔案被挑選的可能性就越大(圖11)。但是，請注意，大量開發人員修改檔案意味著大量的檔案推送。
六、相關工作
持續部署是從敏捷軟體開發[16,17,18,19]到持續整合[20,21,22]到持續交付[7,23]的自然延伸。敏捷開發，軟體迭代開發，週期短至半天，開始於20世紀90年代後期，現在在許多組織以不同形式使用著。持續整合是在每個軟體週期結束時整合軟體更新的做法；這樣可以通過自動構建和自動測試來驗證整合，以儘快發現整合錯誤。持續交付可以使公司更進一步，確保可以以隨時將其釋出到生產環境的方式來構建和測試軟體。持續部署在每個軟體更改準備就緒後立即將其部署到生產環境中。
相關的開發包括精益軟體開發[24]，kanban[25]和kaizan [26]。Devops 是將開發和運營兩方面的角色和工具結合起來的行動[27，28]。
在最近的一項研究中，mcilroy 等人指出，在 google play 商店中的10713個移動應用程式(2013年初 google play 商店30個類別中的前400個免費應用程式)中，1% 的應用程式部署頻率超過一週一次，14% 的應用程式至少每兩週部署一次。雖然這項研究基於一個相對較小的時間範圍，但它表明許多組織正在積極進行持續部署。
然而，文獻中只有有限的明確提到了移動軟體的持續部署。Klepper 等人擴充套件了他們的敏捷過程模型，以適應移動應用[30]。Etsy 是持續整合的負責人，在會談中介紹了他們如何對移動應用程式進行持續整合; 很高效，他們每天將更新下發到每個員工移動終端
關於測試，Kamei等。評估即時品質保證[33]，類似於第4節中描述的策略。高Gao et al. 講解移動測試作為移動軟體開發的一個基礎服務[34]。亞馬遜的Appthwack為此提供了一個移動裝置平臺[35]。
七、結束語
本文描述了 Facebook 移動應用程式的持續部署。更短的釋出週期有許多優點，包括更快的上線時間和更好的響應使用者反饋的能力等等。在四年的時間裡，Android 的釋出週期從8周縮短為1周。我們描述了這段時間學到的東西。
縮短髮布週期迫使組織改進工具、自動化測試和過程。我們觀察到，在 Android 釋出週期從8周減少到1周的四年時間裡，這些改進工具和提高自動化程度的努力代表了使持續部署成功的大部分工作。所收集的資料表明，工具和流程的改進提高了品質，並允許更快的釋出週期。然而，持續部署本身並沒有提供任何生產力或品質改進。
釋出用於移動平臺的軟體更加困難，因為在出現問題的情況下不可能像雲軟體那樣回滾/前進。功能標記用於遠端啟用或禁用功能，以便有故障的功能不需要新版本。如果自動報告此類問題，則Alpha和Beta程式在提供可減少問題的錯誤報告方面非常有效。
分析顯示出幾種導致軟體品質降低的模式：
一個人在分支日期忙於釋出，發現釋出分支被切斷的當天提交的軟體品質較低。縮短髮布週期改善了這一點，因為知道即將釋出另一個版本，開發人員不太可能匆忙進行軟體開發。導致軟體品質降低的另一種模式是，有太多的開發人員同時在同一個檔案上工作，發現每個檔案的問題數量與修改檔案的開發人員數量成比例地增加。八、致謝
我們衷心感謝Laurent Charignon，Scott Chou，Amanda Donohue，Ben Holcomb，David Mortenson，Bryan O’Sullivan，James Pearce，Anne Ruggirello，Damien Sereni和Chip Turner所做的寶貴貢獻，建議和反饋。他們的意見極大地改善了本文。
參考[1] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at Facebook and OANDA,” in Proc. 38th Intl. Conf. on Software Engineering, (ICSE16), May 2016, pp. 21–30.
[2] C. Parnin, E. Helms, C. Atlee, H. Bought, M. Ghattas, A. Glover, J. Holman, J. Micco, B. Murphy, T. Savor, M. Stumm, S. Whitaker, , and L. Williams, “The top 10 adages in continuous deployment,” IEEE Software, accepted for publication, 2016.
[3] J. Allspaw and P. Hammond, “10 deploys per day — Dev and Ops cooperation at Flickr,” 2009, slides. [Online]. Available: http://www.slideshare.net/jallspaw/ 10-deploys-per-day-dev-and-ops-cooperation-at-flickr
[4] M. Brittain, “Continuous deployment: The dirty details,” Jan. 2013. [Online]. Available: http://www.slideshare.net/mikebrittain/ mbrittain-continuous-deploymentalm3public
[5] T. Schneider, “In praise of continuous deployment: The Wordpress.com story,” 2012, 16 deployments a day. [Online]. Available: http://toni.org/2010/05/19/ in-praise-of-continuous-deployment-the--word\\ -press--com--story/
[6] G. Gruver, M. Young, and P. Fulgham, A Practical Approach to Large-scale Agile Development — How HP Transformed LaserJet FutureSmart Firmware. Addison-Wesley, 2013.
[7] J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.
[8] D. Feitelson, E. Frachtenberg, and K. Beck, “Development and deployment at Facebook,” IEEE Internet Computing, vol. 17, no. 4, pp. 8–17, 2013.
[9] A. Reversat, “The mobile device lab at the Prineville data center,” https://code.facebook.com/posts/300815046928882/ the-mobile-device-lab-at-the-prineville-data-center, Jul. 2016.
[10] https://www.chef.io/chef/.
[11] https://developer.apple.com/reference/xctest.
[12] http://junit.org/.
[13] http://robolectric.org.
[14] P. Steinberger, “Running UI tests on iOS with ludicrous speed,” https://pspdfkit.com/blog/2016/ running-ui-tests-with-ludicrous-speed/, Apr. 2016.
[15] https://github.com/facebook/ios-snapshot-test-case/.
[16] K. Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000.
[17] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas, “Manifesto for agile software 22 development,” 2001. [Online]. Available: http://www.agilemanifesto.org/
[18] A. Cockburn, Agile Software Development. Addison Wesley Longman, 2002.
[19] A. Cockburn and L. Williams, “Agile software development: It’s about feedback and change,” Computer, vol. 36, no. 6, pp. 39–43, 2003.
[20] L. Williams, “Agile software development methedologies and practices,” in Advances in Computers, vol. 80, 2010, pp. 1–44.
[21] M. Fowler and M. Foemmel, “Continuous integration,” Thought-Works) http://www.thoughtworks.com/Continuous Integration.pdf, p. 122, 2006.
[22] P. M. Duvall, Continuous Integration. Pearson Education India, 2007.
[23] L. Chen, “Continuous delivery: Huge benefits, but challenges too,” IEEE Software, vol. 32, no. 2, pp. 50–54, 2015.
[24] M. Poppendieck and M. A. Cusumano, “Lean software development: A tutorial,” IEEE software, vol. 29, no. 5, pp. 26–32, 2012.
[25] D. J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
[26] M. Poppendeick and T. Poppendeick, Lean Software Development. Addison Wesley, 2002.
[27] M. Httermann, DevOps for developers. Apress, 2012.
[28] J. Roche, “Adopting DevOps practices in quality assurance,” Communications of the ACM, vol. 56, no. 11, pp. 38–43, 2013.
[29] S. McIlroy, N. Ali, and A. E. Hassan, “Fresh apps: an empirical study of frequently-updated mobile apps in the google play store,” Empirical Software Engineering, vol. 21, no. 3, pp. 1346–1370, 2016.
[30] S. Klepper, S. Krusche, S. Peters, B. Bruegge, and L. Alperowitz, “Introducing continuous delivery of mobile apps in a corporate environment: A case study,” in Proceedings of the Second International Workshop on Rapid Continuous Software Engineering, ser. RCoSE ’15, 2015, pp. 5–11. [Online]. Available: http://dl.acm.org/citation.cfm?id=2820678.2820681
[31] J. Miranda, “How Etsy does continuous integration for mobile apps,” https://www.infoq.com/news/2014/11/ continuous-integration-mobile/, Nov. 2014.
[32] K. Nassim, “Etsy’s journey to continuous integration for mobile apps,” https://codeascraft.com/2014/02/28/ etsys-journey-to-continuous-integration-for-mobile-apps/, Nov. 2014.
[33] Y. Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha, and N. Ubayashi, “A large-scale empirical study of just-in-time quality assurance,” IEEE Transactions on Software Engineering, vol. 39, no. 6, pp. 757–773, 2013.
[34] J. Gao, W.-T. Tsai, R. Paul, X. Bai, and T. Uehara, “Mobile Testing-as-a-Service (MTaaS) — Infrastructures, issues, solutions and needs,” in 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering, 2014, pp. 158–167.
[35] https://aws.amazon.com/device-farm.
譯者：IDCF社群翻譯組