IMVU如何在實施持續部署的同時確保軟體質量

2010年4月9日 James Birchler 原文連結

在科技圈的各種大會上，我們和很多人有過交談，他們對我們在IMVU上的持續部署流程很感興趣，想知道我們是如何每天部署50次程式碼的。我們也聽到一些問題，關於我們是如何做到在不引入新缺陷和迴歸問題的情況下使用這種方法，以及我們是如何在這樣快節奏的環境中保障質量的。

事實是我們有時候也會因為搶速度而對顧客造成一些負面影響，而這些特性也是我們學到教訓的來源。有時候我們做出的特性對於顧客沒有什麼價值，有時候會在生產環境中引入一些迴歸問題或是新的缺陷。

但是同時，我們小心翼翼做出的特性客戶也曾經並不感冒——而這實際上耗費更多，因為我們花了更多的時間來學習和改變方向。舉一個例子，我們曾經用了一個月的開發時間忙活一個叫做“更新”的特性——有點像Facebook的“Friend feed”（朋友新鮮事），而使用者使用這個特性的方法和我們預估的完全不同。我們花了很長的時間交付了一個沒有人需要的功能，而結果就是這延後了一個更加重要特性的交付，那就是：群組。

問問使用者他們想要什麼，節省了內部產品開發討論的時間，使解決很多問題變得簡單，“我們應該做一些工具讓使用者把阿凡達裝備分類，還是直接做一個搜尋工具，還是兩個都做？”我們會在已有客戶資料、競爭分析以及綜合經驗的基礎上做一個儘量好的決定——然後儘快地做出一個功能，用客戶來驗證我們是否正確。

我們還發現在這過程中的代價——主要是缺陷和不太精細但是好用的特性——是值得的，這是因為我們能從顧客那裡儘快得到關於產品創意的第一手反饋。一旦從客戶那裡得到反饋，就可以確定我們關於產品的設想和決策是否正確，我們也就能夠更快地改變路線或是在一個好創意上增加投入。

你覺得我們並不擔心如何給客戶提供高質量的特性，或是他們的使用者體驗會受到影響嗎？我們擔心得不得了。

首先，我們很重視自動測試。這種對於測試和其框架的重視是我們如何架構QA團隊和其使用方法的核心。我們的前CTO，也是IMVU的聯合創始人Eric Ries曾經詳細地描述過我們用來支援持續部署的基礎設施，這裡概括一下，我們是這麼做的：

• 每一行提交程式碼都用一個持續整合伺服器（Buildbot）執行監控自動測試
• 為了確保出問題的時候不讓新程式碼加入程式碼庫需要執行一個源控制提交檢查
• 為了保障萬無一失，需要在部署軟體到叢集時加一個指令碼。我們編寫了一個叢集免疫系統來監測和對嚴重的迴歸問題發出警告，當發生錯誤時，自動回滾到上一個好的版本
• 如果錯誤不小心加入到了部署過程中，實時監控和警報會在第一時間通知團隊
• 根因分析（五個為什麼）可以驅動部署和產品開發流程中的不斷改善

這個框架和自動測試就意味著軟體工程師必須為我們編寫的每行程式碼都編寫測試。我們並沒有一個單獨的角色來編寫測試和研究基礎設施——這個工作是由整個工程團隊承擔的，這是能保持QA團隊精簡的原因。但是用這樣的方法也不能防止所有的迴歸問題和缺陷。有一些使用者使用例項，而有一些例項過於邊緣，複雜到無法使用自動化的測試。活生生的人還是比可以做多維、多層測試的機器要聰明。我們的QA工程師依靠他們的洞察力和經驗在實戰中發現潛在的問題，他們用客戶可能使用的方法來使用並且測試特性。

QA工程師會用幾乎一半的時間手動測試特性。一旦發現測試例項可以自動化，我們就會把它加入到測試覆蓋範圍（在Scrum流程中，其中的一個環節可以確保我們能夠捕捉到了這類測試用例）。在Scrum流程中有一步要求工程師向另一個成員展示特性，——其實就是在有人在場的情況下，做一些基本的手動測試。因為我們需要構造的特性比QA工程師有時間測試的要多得多，這就使得團隊必須要做一些權益取捨，回答這樣的問題：“哪些特性值得QA花時間來做？”有時候這個問題不是那麼容易回答的，也使得團隊開始考慮是不是應該讓其他成員，甚至是整個公司加入到更有組織更有規模的測試環節中來。當我們覺得這是行得通的時候，QA工程師就會組織這樣的測試環節，幫助團隊更快地發現和分類問題。

我們的QA工程師還有兩個更重要的責任。第一個就是Scrum計劃流程中的重要組成部分，編寫測試計劃並和產品所有者和技術帶頭人一起做評估。這能確保重要客戶的用例沒有被遺漏，而且保證工程團隊知道特性將怎麼測試。也就是說，QA工程師幫助整個團隊認識到顧客會如何使用他們正在搭建的特性。

第二個責任就是大家眾所周知的QA工程師在敏捷環境中的作用：他們在特性開發階段就和軟體工程師一起工作，同時儘量多地測試程式中的特性並和整個團隊面對面地討論這些特性。當功能最終應該“交由QA處理”的時候，它們實際上已經被測試過了，而且很多潛在的缺陷已經被發現和修補過了。

無論在釋出前已經進行過多少次手動測試，我們最終還是會依靠自動化：基礎設施允許我們完成控制條件下的轉出，而我們的叢集免疫系統對於迴歸問題的監測也減少了對顧客產生負面影響的風險。

最後，當特性呈現在顧客眼前的時候，我們會等待A/B分裂實驗系統的實驗結果，並傾聽社群管理和客戶服務團隊的反饋。當反饋開始增加的時候——通常是馬上，我們已經是準備好了的。我們已經特地為報告的缺陷和問題留出了快速反應的工程時間，也為讓特性更加有趣的一些小變化做好了準備。

我們絕非完美：一直努力迅速向使用者傳遞價值但是QA資源有限，也經常在生產過程中引入缺陷並且提交不完美的功能。但重要的是，我們能馬上就知道使用者想讓我們做什麼，然後一直迭代。