1 持續集成、即時反饋與LavaLamp
即時反饋對於持續集成模式來講非常重要。事實上，它是持續集成的精髓所在。當某一個CI構建任務出現問題時，應當將該失敗信息即時反饋給相關同學（包括 RD、QA和其他關心代碼CI情況的同學），以便觸發者或其他依賴於該構建過程者及時改正或回滾代碼，快速迭代解決問題。如果沒有這樣的即時反饋機制，僅 僅依賴於人工關注hudson等CI Server界面的話，會造成響應速度變慢且不可控，問題修復週期延長，進而破壞持續集成的有效性。
目前可用的持續集成即時反饋手段很多，包括Email羣發、短信息羣發、RSS訂閱、GTalk通知，甚至Twitter消息等。其中一種令人耳目一新的解決方案是“LavaLamp”，即我們俗稱的“神燈”。
圖1：LavaLamp 神燈
LavaLamp本質上是一盞USB燈，放在一臺靠近持續集成團隊的臺式機上，通過安裝對應的CI Server插件，能夠使用不同的顏色顯示指定持續集成任務的當前狀態（譬如紅色表示失敗、黃色表示部分失敗、綠色表示成功）。此外它還能在持續集成任務 失敗或部分失敗時，以警報聲（Beep）的方式引起注意。LavaLamp還能活躍團隊氣氛，讓持續集成實踐團隊處在一種比較酷的氛圍中，進而調動其成員 解決問題的積極性。百度的Ecom部門目前已經有產品線採用了商業化LavaLamp解決方案，在持續集成過程中使用效果不錯，但需要一些資金投入。
毛主席教導我們：“要多快好省地建設社會主義”，而鄧小平同志也教導我們：“不管黑貓白貓，逮着老鼠就是好貓”。
因此，本文將基於hudson平臺（現在已經改名爲Jenkins了）探討一種免費的持續集成即時反饋解決方案，能達成與Lavalamp 神燈同樣甚至更好地視覺和聽覺效果，再通過配合其他的即時反饋手段（譬如百度HI羣），實現有百度特色的持續集成之路。
2 讓顯示器客串Lavalamp
Lavalamp的思路其實很簡單：把持續集成構建任務的狀態暴露在大衆視線之下，而不是湮沒在CI Server或瀏覽器中。只不過其實現是基於特定設備（USB燈及其控制器），需要投入一些成本。
那麼，有沒有免費的的視覺效果解決方案呢？當然有！那就是咱們——顯示器。
事 實上，hudson官方網站上已經提供了一個非常好的插件，名叫Extreme Feedback Panel（簡稱XFPanel，http://wiki.hudson-ci.org/display/HUDSON /eXtreme+Feedback+Panel+Plugin）。顧名思義，該插件提供了一種特殊格式的hudson視圖，當在瀏覽器上訪問該視圖時， 它會將視圖內各個Job的當前狀態以醒目的方式顯示出來。如果使用瀏覽器的全屏功能（按F11切換），就能達到如下圖所示的效果：
這樣，咱們工位上閒置的LCD顯示器就能成功客串爲LavaLamp 啦。而且LCD顯示的信息要比LavaLamp多得多。後者只能通過顏色變化提示，而大家無法獲知是哪個job掛了，具體信息還是得上CI界面上查看。而 通過XFPanel插件，團隊成員能一目瞭然各個Job的當前狀況，甚至還能獲知是誰commit代碼引發了問題，以及QA的Quick Test Case失敗了幾個，這樣更能體現持續集成的速度優勢。
那麼，該如何使用該插件呢？
首先，請從hudson官方網站下載XFPanel插件爲.hpi文件，並在hudson的插件管理界面導入該插件，當然別忘了重啓hudson服務器。這個過程本文不再贅述。
然後，點擊新建視圖，並選擇視圖類型爲“eXtreme Feedback Panel”，如下圖所示：
接下來，點擊OK，在視圖設置界面進行配置。如下圖所示：
上述設置完畢後，該Extreme Feedback視圖就算搞定了。請切換到該視圖上，然後按F11鍵，將瀏覽器窗口切換到全屏。此外，你還需要在Windows中設置爲“從不關閉顯示 器”和“從不休眠”，並關掉屏幕保護程序（如下圖所示）。最後，把顯示器放在大家都能看到的高處。於是一臺功能強悍的顯示器版LavaLamp就誕生啦。
與Lavalamp相比，使用顯示器的好處是成本爲0，且提供的信息更爲豐富，界面也更爲醒目。當然，由於顯示器的耗電量要比lavalamp大，因此建議踐行該方法的CI團隊多去開展植樹活動，消除由此帶來的碳足跡。
3 讓音箱發出任務失敗報警
僅 僅由LCD顯示器顯示出持續集成任務的狀態信息還是不夠的，因爲在工作時大家都很投入，保不準就能及時看到顯示器上那大大的紅色感嘆號。在成熟的解決方案 中，當關注的持續集成任務失敗或者部分失敗時，LavaLamp應當隨即發出“嘟——嘟——”的報警音頻，敦促責任人馬上着手解決問題。 而上一節介紹的XFPanel並沒有提供這樣的音頻功能。
Hudson官方網站上也提供了兩個插件來嘗試解決該問題，分別叫做 Hudson Sound 和 Hudson Speak。 二者都是在Job的Notify階段設置，所不同的是，前者能播放提前準備好的.wav音頻，而後者則通過TTS技術將一段文本讀出來。
這 兩個插件雖然很酷，但都要求將hudson服務器安裝在一臺擁有聲卡設備的服務器上，並且最好是Windows服務器（因爲Linux服務器即便有聲卡， 其驅動情況也過於複雜）。當播放報警音頻時，這兩個插件都只能在Hudson 服務器本機上播放。也就是說，必須將Hudson服務器搬到工位附近，而不能放在機房裏。
但在目前百度辦公網環境中，這樣做是不靠譜的，有如下理由：
※辦公網中的Windows機器沒有域名，訪問不便。
? ※ 放在工位上的服務器很容易斷網、IP失效甚至斷電，讓CI服務的穩定性無從談起。
? ※ 所有辦公網中的計算機都訪問機房都要通過IDC機房隔離，且需要BNAC系統准入，在端口上有層層限制。
因此，直接使用Hudson音頻插件是此路不通的。需要另行尋找其他解決途徑。
通過多次摸索和實驗，基於Hudson提供的Post Build Task插件（主頁爲 http://wiki.hudson-ci.org/display/HUDSON/Post+build+task），我們有了一個解決方案。
Hudson Post Build Task插件安裝後能在Job配置頁面最後添加一套“Post Build Task”流程。該流程能在Job結束前檢查STDOUT輸出日誌內容，通過一些指定的字符串進行匹配。當滿足給定的字符串匹配條件時，就會觸發執行指定 的腳本。
因此，這裏我們的思路如下： 通過Post Build Task插件監視持續集成任務輸出中有沒有“Build Fail”字符串，若出現該字符串，說明構建失敗，則遠程通過slave.jar運行上一節顯示器所述臺式機上的一段腳本發出報警聲。
具體做法如下：
? · 第一步：請下載和安裝Post Build Task插件，並重啓Hudson服務器（這裏不再贅述）。
? ·第二步：請將上一節客串Lavalamp的顯示器所屬臺式機（這裏簡稱其爲“公告機”）加入Hudson節點池中。建議使用JNLP方式啓動其Slave.jar（這裏也不再贅述如何添加windows節點）。
·第三步，請創建一個負責發出報警聲的Hudson任務，名爲“BuildFail_Notice”。該任務的功能非常簡單——綁定到上述“公告機”，並觸發windows的錄音機程序播放事先準備好的.wav格式報警音頻
上述命令中，錄音機的可執行文件路徑爲C:\WINDOWS\system32\sndrec32.exe， 在命令行下執行時。使用/play參數表示播放指定文件，使用/close參數表示播放完畢後退出錄音機程序，而通過/embedding參數來表示後臺 方式執行，即不在Windows界面上顯示錄音機程序，以免影響持續集成XFPanel視圖。
請注意，這裏的build step類型應當是Windows Batch腳本。
完成本步驟後，請將準備好的.wav文件放在公告機的c:\BuildFail.wav路徑處，然後手工觸發該任務，調試一下，看是否能發出報警音頻。
·第四步，在各個需要失敗報警的Hudson任務中，增加Post Build Task步驟，其意圖是：當匹配到Build Fail或其他能表徵Job失敗的日誌時，就通過Hudson CLI命令行方式調用第三步準備好的失敗音頻報警任務。其Post Build Task配置如下圖所示。其中：
?* 需要提前將hudson-cli.jar包放到各個Hudson Slave節點上去，該Jar包在hudson.war中可以找到；
?* 調用hudson-cli.jar包時，-s參數表示hudson服務器的URL地址，請根據自己部署hundson環境的實際情況填寫
?* 調用hudson-cli.jar包時，使用build參數表示要構建一個任務，後面跟着被執行的任務名。在這裏要執行的就是負責發報警音頻的BuildFail_Notice任務。
?* 在這裏，你還可以配置更多的字符串匹配條件，並通過AND或者OR關係將他們組裝起來，成爲一套更復雜的觸發條件。此外，還能爲不同的觸發條件觸發不同的腳本，譬如爲Fail的任務觸發一個聲音，再爲Unstable的任務觸發另一種聲音。
完成上述四個步驟後，一套不花一分錢的音頻觸發解決方案就搞定了。該方案看上去有些複雜，但設置起來其實一點也不麻煩。而且，其靈活性非常強，譬如：
? #你可以錄下自己的聲音作爲持續集成報警音
? #你可以爲不同的持續集成任務提供不同的報警音，這樣光聽到聲音就知道是哪個任務掛掉了
? #你可以爲同一個持續集成任務的不同狀態觸發不同的報警音，這樣聽聲音就知道該任務是哪個失敗狀態了
? #你可以爲某個特定的字符串觸發報警音，而不僅僅侷限於任務失敗場景，譬如當執行Case成功率低於50%的時候再發出報警
? #等等…… 總之，只有想不到，沒有做不到！
你或許要問，爲什麼不能直接使用遠程調用的方式觸發windows發報警音呢？You are right，通過SSH、Python rpyc乃至自己手寫Daemon的方式來遠程觸發播放報警音頻看上去更爲直截了當，但在實踐過程中會碰到問題，那就是“IDC隔離”。
所 謂IDC隔離，是將百度辦公網段和服務器網段隔離開來，從辦公網只能訪問服務器網段的有限範圍的端口，而從服務器網段則能訪問辦公網段的任意端口，即單向 端口隔離。這樣就帶來一個問題：目前Hudson服務器是位於服務器網段內的一臺Linux服務器上，而負責播放失敗報警的Windows臺式機則位於百 度大廈的辦公網段中。以SSH遠程調用爲例，當從Hudson服務器直接發起SSH請求到這臺windows臺式機時，根據Socket基本規 則，Hudson服務器訪問的是Windows臺式機的22端口，而後者則訪問前者動態分配的端口。這個動態分配的client端口範圍是無法限定的，基
本不會落在IDC隔離所允許的端口窗口範圍內。因此，造成從Linux服務器直接向辦公網臺式機發遠程調用請求會失敗。
而Hudson的slave.jar機制不存在上述問題，因爲Slave.jar是主動去連Hudson服務器的指定端口的，只要將hudson服務器的監聽端口設置在窗口範圍內，則各個節點的Slave.jar就都能連上去並執行hudson要求的任務。
綜上所述，我們不得不捨近求遠，採用了一個看似曲折，實則曲徑通幽的解決方式。
4 後話
其 實即時反饋的方式有很多。譬如最簡單的就是羣發郵件。此外還可以通過即時通信軟件、安裝在桌面上監聽軟件、手機、RSS訂閱等方式實現任務狀態的即時廣播 提醒。你可以根據自己的需求，安裝對應的hudson插件來使用這些功能。這些插件可在hudson官方網站找到，URL 爲：http://wiki.hudson-ci.org/display/HUDSON/Plugins#Plugins- Buildnotifiers
但這些解決方案中，都沒有提到咱們百度人每天必用的Baidu HI，也不包括QQ等國產IM軟件。有志於hudson插件的同學可以考慮爲這些國產IM軟件開發對應的插件，讓咱們的IM軟件業去露露臉。
其實除了插件之外，我們也可以通過其他方式來在Baidu HI羣上自動發出任務狀態通知。大體思路是：
? ·step1：爲某一項目的持續集成專門註冊一個baidu hi賬號，並加入該項目的hi羣
? ·step2：基於Sikuli或Watin或其他Web端自動化工具，編寫一段腳本，訪問http://web.im.baidu.com/，用該賬號登陸併發送通知到項目Hi羣中
? ·step3：使用Post build task插件，當匹配到符合條件的情況是，調用step2的腳本，訪問網頁版百度HI發出通知消息。 如果服務器無法直接訪問外網，可參考前面解決音頻問題的思路，將該腳本調度到辦公網環境的一臺臺式機上運行。
總而言之，在持續集成的道路中，只有想不到，沒有做不到。同學們，發揮你們的聰明才智和創造力，讓我們的持續集成之路走得更加意氣風發，更加樂趣無窮！