> 作者 Sai Yang，譯者 楊賽 發布于 2014年8月5日
[OpenStack](http://www.openstack.org/)社區有一個CI和自動化測試小組，該小組為OpenStack社區的開發者們提供服務，而該服務所用的工具正是他們自己維護的一個OpenStack云環境。
對于這樣一個囊括了十數個子項目，每月有300多位開發者提交代碼的復雜項目，普通的CI系統是難以處理的。
我們跟該小組的負責人[MontyTaylor](http://www.hpcloud.com/author/monty-taylor)和[JamesBlair](http://www.linkedin.com/pub/james-blair/36/1b2/98a)溝通，了解他們在構建和測試過程中所面臨的挑戰，以及他們是如何解決這些挑戰的。
**InfoQ**：你們的CI系統每天處理多少次提交？你預計到Icehouse版本發布時會有多少？（注：本采訪完成于2013年11月，當時距離Icehouse發布還有半年）
**Monty**：
> 印象中，我們的系統最高處理過每日400 次提交。這些僅僅是通過測試的部分，實際上我們的測試量要大于這個數字，因為只有通過測試的代碼才會進入CI 。
**Jim**：
> 每次提交被審查之后，我們在實施合并之前會再做一輪測試。
**Monty**：
> 對于每個被合并的提交，我們都會對其做8-10 個不同的測試任務。因為測試會在上傳的時候和合并之前各做一次，相當于每次變更我們都會跑將近20 個測試任務。有一段時間我們的系統一天就跑了10000 個任務。
> 從Grizzly 到Havana ，我們的集成、測試量基本上增加了一倍。基本上每個新版本我們都會增加一倍的量，到Icehouse 應該也是如此。
**InfoQ**：你們都跑哪些測試任務？
**Jim**：
> 首先是代碼風格檢測。因為我們的協作開發者人數眾多，因此代碼風格統一是非常重要的，我們需要確保大家都使用同樣的編碼方式。這是個很簡單的任務，但很重要。
> 然后是單元測試，僅僅測試被變更的子項目，不考慮跟其他子模塊之間有網絡交互的情況。我們針對幾個不同的平臺做測試，包括2.6 、2.7 和3.3 ，基本上我們在CentOS 上跑2.6 ，在
Ubuntu 上跑2.7 。
> 然后是集成測試。我們用
[DevStack](http://devstack.org/)
> 將所有的組件安裝起來，然后在安裝起來的這個單節點云實例上跑不同的模板。不同的模板對不同的模塊進行不同的設置，比如使用不同的數據庫、不同的消息隊列。可以選擇的種類很多，不過基本上我們只測試那些常用的，比如
[MySQL](http://www.mysql.com/)
> 、
[PostgreSQL](http://www.postgresql.org/)
> 、
[RabbitMQ](http://www.rabbitmq.com/)
> 這些。
**Monty**：
> 我們最近也在考慮引入
[ZeroMQ](http://zeromq.org/)
> 的測試。
**Jim**：
> 如果社區里認為某個子模塊比較重要，使用的人也越來越多，也有更多的人愿意參與到
debug
> 工作當中，那我們也會將這個模塊加入。
**InfoQ**：測試任務是由誰來寫的？
**Monty**：
> 開發者自己寫。我們的
QA
> 團隊很小，基本上只關注測試系統本身的工作，不會有太多精力去關注測試任務本身。所以我們要求開發者自己提供單元測試和集成測試。
**Jim**：
> 我們最近在討論的一個話題就是在這方面做更嚴格的限制，即只有寫好了集成測試的變更提交才能夠被接受。
**Monty**：
> 我們總覺得未經測試的變更就是有問題的。一般來說的確是這樣。
**Jim**：
> 現在項目發展的這么快，有這么多組件，這里或那里的一個小錯誤可能就把整個系統搞死。
**InfoQ**：性能測試有在做嗎？
**Jim**：
> 還沒有，不過我覺得可能差不多可以啟動了。我聽說
BorisPavlovic
> 正在做一個叫做
[Rally](https://wiki.openstack.org/wiki/Rally)
> 的測試系統，
JoeGordon
> 則在進行一些可擴展性測試的工作——跟性能測試不太一樣，不過關聯比較大。這都是我們希望做的事情。
> 我們的測試顯然沒有覆蓋所有的方面，不過我們最終希望測試所有的東西，當然這需要時間。
> 在本次發布周期內，我們關注于升級測試。現在我們已經在做一些，不過做的還不夠，需要做更多。
**InfoQ**：在一個實例上運行一個測試任務大概需要多久？
**Monty**：
> 一般在20-40 分鐘，具體時間長短跟實例的配置有關。
**Jim**：
> 我們花了很多精力讓測試變得并行化。我們構建了一個叫做TestRepository 的框架，大多數單元測試在這個框架中已經可以并行處理，測試結果出的很快。
**Monty**：
> 還有Jim 寫的[Zuul](https://github.com/openstack-infra/zuul) ，這個工具可以一方面并行的測試成套的變更，同時又保持他們的測試順序不變。
**InfoQ****：運行測試用到了多少機器？用于運行測試用例的實例配置是怎樣的？**
**Monty**：
> 我們自己是沒有機器的。所有的測試都跑在公有云上，有些來自Rackspace ，有些來自
HP ，都是贊助的。他們沒找我們要錢，而我們需要多少就可以用多少。
**Jim**：
> 上一個版本周期內，最高的時候我們并行跑了340 個實例，一個實例就是一個VM 。集成測試一般使用很基礎的VM——8GB 內存，系統是UbuntuPrecise 。我們把這個節點搞起來，然后讓
DevStack 在這個VM 上安裝OpenStack 。
**Monty**：
> 實際情況要比這個復雜，不過大概意思就是這樣。我們有一個
[nodepool](https://github.com/openstack-infra/nodepool) 用來管理這些VM ，通過緩存來預備這些機器。我們需要將DevStack 需要的依賴等東西都預先下載到本地，這樣測試本身就可以離線運轉。
**Jim**：
> 測試跑完之后，我們再銷毀這些VM 。實際創建的VM 數量要比跑成功的測試數量多，因為
Zuul 的隨機機制，有些時候它的測試跑到一半的時候才發現還需要一些其他東西，于是測試跑不下去了，我們會干掉這個VM ，起一個新的。一個大致的比例是，如果一天跑10000 個任務，那么啟動的VM 數量差不多在100000 的量級。
**InfoQ**：可以認為用于OpenStack的Zuul模式是nviegit分支模式的一個改進嗎？感覺Zuul似乎不適合分支過多的情況。
**Monty**：
> 實際上我們是不采用nviegit 分支模式的，因為我們用了[Gerrit](https://code.google.com/p/gerrit/) ，所以我們的代碼提交模式跟Linux 內核的模式更像：人們在郵件里交換補丁。我們的做法不是建立很多的分支然后做合并，而是讓每一個變更形成一個虛擬的私有分支。相對于將每一次變更生成一個新的commit 并增添至分支的頂端的做法，我們的做法是：在之前的一次修改之上再進行修改。我們的測試針對每一個獨立的
commit ，而不是針對一個分支。
> 每一個開發者可以建立本地的分支，這些分支是私有的，沒有什么發布機制。我并不知道
Jim 的筆記本上的分支是什么樣的。我自己用git 的方式比較奇葩，我不用分支，而是每次在我的master 上重置ref—— 這是個非主流的用法，git 新手最好還是不要這么嘗試。
> 所以，OpenStack 的git 補丁流程其實是基于Gerrit的。
**Jim**：
> 另外，我們需要確保審查人員審查的對象是每一個commit （而不是分支）。理想狀態下，每一個進入項目的commit 都被人仔細的檢查過。分支的話就會比較混亂。把每一個commit 把關好，把好的commit 合并，是比較精細的做法。
**InfoQ**：除了**Zuul**之外，你還提到了在**Jenkins**上使用**Gearman**來提高可擴展性，使用**Logstash**做**debug**，還有你上面提到的**TestRepository**將測試輸出自動發給**committer**。目前的反饋機制是如何運轉的？理想的情況是怎樣的？
**Monty**：
> 反饋機制整體來說是越來越好的。你的問題涉及到幾個方面。有關用Gearman 來提高
Jenkins 的可擴展性這一點，首先Jenkins 本身的設計是針對一個master 的情況，讓它支持多個節點是通過hack 的方式來完成的。我們一開始的用法是跑一個Jenkinsmaster 和若干個
slave ，并行跑的測試任務數量要比正常的Jenkins 用法要多很多。Jenkins 在設計當中涉及到很多全局鎖，所以要像我們這樣用起來，會遇到很多可擴展性的問題。
**Jim**：
> 因為Jenkins 在設計的時候根本沒考慮過我們這樣的用法。
**Monty**：
> 所以我們就寫了Gearman 插件，這個插件的作用是讓Jenkins 將所有任務注冊為潛在的
Gearman 任務，標記在Gearman 服務器上。這樣一來我們就可以針對一組測試任務建立多個
Jenkinsmaster ，讓Gearman 來做任務分發，如果一個Jenkinsmaster 開始遇到瓶頸，我們就讓Gearman 把任務分發到下一個Jenkinsmaster 上。
**Jim**：
> 一般來說，一個Jenkinsmaster 帶100 個slave 之后就會遇到問題。我們要同時跑
340 個任務，那就需要3.4 個Jenkinsmaster 來處理。
**Monty**：
> Logstash集群是個很有意思的東西。每一次DevStack 安裝的是整個的云環境，然后針對這個小環境跑測試。僅僅是安裝的過程就會制造很多日志，包括Nova 、Glance 等等。如果遇到問題，開發者根本無從下手去debug ，能夠依賴的只有日志。所以，我們把所有的日志丟到一個很大的Logstash 集群當中，這個集群通過elasticsearch 的方式給所有的log 建索引。這樣，開發者就可以進去查看日志，了解到底發生了什么問題。這里面的
[ElasticRecheck](https://github.com/openstack-infra/elastic-recheck) 是
JoeGordon 、SeanDague 和ClarkBoylan 寫的。
**Joe**：
> 那個圖表功能是我寫的。
**Monty**：
> 比如我們發現有一個任務導致測試跑失敗了，我們會在
LogStash
> 上運行腳本，來檢測這是否是我們之前見到過的錯誤類型。如果有匹配，我們會在郵件通知里將之前的
bug
> 報告附上，這樣會幫助開發者更快的定位問題。
**Jim**：
> 這其實是很酷，也很獨特的。世界上像這種規模的項目是很少的，這種規模的測試、這種規模的日志，開發者很少能夠在其他項目獲取到。云平臺這樣的項目，開發者在自己的機器上是很難去發現代碼可能會引起的問題的，因為很多問題都是要跑很多次不同的測試才能抓到——而我們的測試平臺可以做到這一點！下一個發布周期內，我們會嘗試讓問題識別變得更加自動化，將變更和行為的特征更多的抽取出來，幫助開發者更快的定位問題。
**InfoQ**：你們做的這一大堆自動化測試的工作，感覺最難的地方是在哪里？
**Monty**：
> 開發者很多，代碼很多，測試需求量每6 個月都會增長一倍。面對commit 數量如此眾多、快速增長的情況，我們需要提前預見到可能發生的問題，做好準備——因為如果真的遇到了問題，那么那個時候再去開發系統來解決問題就來不及了。自動化解決的問題不是今天的問題，而是三個月之后的問題。
> 正因為所有的測試都在我們這里，我們就必須確保這個系統一直能夠正常運轉。你的測試一天跑10000 次，萬一系統出了問題，給開發者發郵件說你的代碼有錯（而實際上根本不是他們代碼出了錯，是系統本身出了錯），那就會很糟糕。誤報比不報更糟糕，所以自動化必須做的非常靠譜。
> 還有就是，我們總是會遇到網絡中斷的問題——基本上我們有一半的時間都用來處理這個問題。所有的網站都會連不上：平時你自己去刷網頁是感覺不到的，但如果你一天跑10000 次自動化測試呢？如果Github 平均有1% 的時間是不可用的，你作為用戶去刷頁面沒打開，重試一次就好；而我的測試系統每天從Github 做10000 次抓取，1% 的不可用就相當于100 次失敗。
> 由于我們在跑的這個系統，我們也成了RackSpace 和HP 云的性能監控器。很多時候我們發現有一個問題，就去問他們的運維：“你們這個數據中心是不是網絡出問題了？”然后他們會說：“對啊！我們也剛剛發現！”
**Jim**：
> Rackspace 和HP 云都是基于OpenStack 的系統，所以我們的測試系統是在OpenStack 上運行、為OpenStack 做測試。用自己測試自己的代碼，同時又測試自己的運行狀態，這是個很酷的事情。
## 受訪者簡介
MontyTaylor是HP杰出工程師，OpenStack技術委員會成員、OpenStack基金會個人董事。他帶領OpenStack基礎架構項目、Ironic項目和TrippleO項目。
JimBlair現在是OpenStack基礎軟件組的核心開發者，也是OpenStackCI項目的核心開發者。他也是OpenStack技術委員會成員，OpenStack基礎架構項目的技術領導者。他目前任職于OpenStack基金會。
**查看英文原文：**[MontyTaylor and Jim Blair on CI and Test Automation at OpenStack](http://www.infoq.com/articles/interview-openstack-ci-test-automation)
查看原文：[跟MontyTaylor](http://www.infoq.com/cn/articles/interview-openstack-ci-test-automation)[和JimBlair](http://www.infoq.com/cn/articles/interview-openstack-ci-test-automation)[聊OpenStack](http://www.infoq.com/cn/articles/interview-openstack-ci-test-automation)[的持續集成與自動化測試](http://www.infoq.com/cn/articles/interview-openstack-ci-test-automation)
