“唔哩”，來自于網絡流行語“wuli”，出處在韓語，“我們”的意思。這個畫風相當二次元的詞是90后星人的基本語匯。唔哩是一款為90后年輕一代打造的新聞資訊App，團隊一直致力于以優質內容為基礎，以互動分享與個性化設置為特色，加入場景閱讀新元素，滿足用戶任何時間和狀態下輕松愉快的閱讀需求，做最懂90后年輕一代的貼身伴侶。

作為一款時尚、流行的APP，產品上線之后一直了保持較快的增長速度，經統計自2016年3月份上線以來，4個月后注冊用戶已達400萬、日均活躍用戶數為25萬人次。持續快速穩定的增長不僅與產品本身的話題性、強大功能密不可分，也得益于唔哩技術團隊對用戶體驗的足夠重視，同時也離不開敏捷開發/敏捷運維為產品提供的有力技術支撐。

一、重視持續集成，提升代碼質量

對于創業公司來說，缺乏完善的流程規范和技術平臺，許多開源的技術方案并不能很好的解決面臨的困難，導致產品上線之初各種坑都踩了一遍。比如版本升級后，依賴模塊調用版本不對，已知bug再次復現,數據錯誤等等；為此，唔哩設置了4種環境(dev+test+stage+prod)。

1、dev環境用于各模塊的功能開發，mock接口

2、test環境用于集成測試，集成測試通過之后，可以提交新版本到stage環境運行

3、stage環境是非常接近生產環境的，使用的數據是從生產環境同步過來的，在stage環境運行無異常后，最終提交新版本到prod環境

四個環境的操作系統版本和配置參數及環境變量及服務器架構都是一致的，盡量規避因環境不一致產生新的bug到生產環境。

有了環境，接下來就可以做持續集成了。唔哩采用的比較流行方案：gitlab+jenkins，gitlab做版本控制，jenkins做代碼自動構建、測試和打包以及把代碼自動布署到開發環境。

a)分支模型：gitlab主要分支有兩個:master和develop。

master分支保持用于線上環境的代碼。

develop分支保持下一個release版本最新的代碼，當develop分支的代碼達到release穩定要求時，將develop分支的所有變化合并到master分支并對master打上一個tag(release版本號)。

feature分支用于開發新功能，從develop分支分出來，新功能開發完成之后合并到devleop分支。合并之后就可以刪除此分支了。

release分支主要用于大版本之后發布一些小的改動(如果有大的功能調整需要從develop分支一個feature分支開發)，從develop分支分出來，然后再合并到master分支。合并之后就可以刪除此分支了。

bugfix分支用于bug修復，從主分支創建，然后合并到master分支和develop分支。合并之后就可以刪除此分支了。

gitlab基本不用太多的配置，需要在gitlab上創建一個用戶能pull需要做持續集成的項目，然后在項目的setting里設置webhooks，URL為jenkins生成的GitLabCIServiceURL，trigger可以選Pushevents/Tagpushevents/MergeRequestevents，這樣當向項目push代碼或merge請求的時候就會觸發jenkins的構建job，也可以在jenkins里配置輪詢的方式，每過多長時間檢查一下，如果條件符合觸發構建任務。

b)jenkins需要安裝一些插件：如Junit、Cobertura、GitlabMergeRequestBuilder等。

GitlabMergeRequestsBuilder允許在gitlab上提交mergerequest時候觸發jenkins上配置的相關的構建任務，即在slave上將某個分支合并到另一個分支上，合并之后如果構建成功，就將打包好的文件scp到集成環境的主機上進行布署，最后生成測試報告，并發送郵件到相關的郵件接收人。如果一切正常則可以進行codereview，這樣可以提高codereview的效率，然后在gitlab上真正合并分支。下面是jenkins構建項目的主要項配置及截圖：

參數化構建過程：添加4個String Parameter,名字分別為gitlab Source Repository、gitlab Source Name、gitlab Source Branch、gitlab Target Branch；

源碼管理：勾選Git

唔哩攜手聽云APM：敏捷運維提升產品質量

構建觸發器：勾選GitlabMergeRequestsBuilder,GitlabProject Path填上你的項目路徑(比如：groupName/projectName),Crontabline配置H/5****即可;

Build：RootPom參數為pom.xml,Goalsandoptions參數為:

cleancobertura:coberturapackage；

PostSteps：如下圖

唔哩攜手聽云APM：敏捷運維提升產品質量

二、持續布署，每次變更都會加入跟蹤統計

對于生產環境，唔哩比較謹慎，目前采用的是人工干預的方式來發布到生產環境。利用jenkins自動構建測試之后，將打包好的文件存放到版本倉庫中，然后利用saltstack布署到生產服務器上。在這個過程中，唔哩用python寫了一個web平臺來管理發布流程。

首先定義一個流程，由開發人員提交版本需求，并描述具體變更說明；然后由運維人員操作布署，只需在web界面點擊一下按鈕，后臺自動上線并實時展現日志；接下來由測試人員進行測試，并產生測試報告；最后流程由PM結束，PM決定一次版本上線是否結束，還是需要回退到歷史的版本；版本回退的流程也是一樣的過程，流程的每個節點都有相應的郵件描述說明，方便下一步的人員查看。具體流程及流程的每個節點執行哪些job都是可配置的，功能擴展很方便。 

唔哩攜手聽云APM：敏捷運維提升產品質量

在做這個發版的平臺主要是基于兩個方面考慮:

1、一個是有一些web應用前面都是Nginx做代理，布署后端服務時需要先在Nginx上剔除，布置完后端服務再添加回來，這個需要一個單獨的工具或平臺集中管理不然不好控制;

2、另一個考慮是把每次版本發布都歸檔,包括布署過程中產生的日志信息，方便審計，而且根據對歷史發版發布的統計也可以發現版本發布的質量，當然是布署上線的次數越少越好。

在未來，唔哩考慮讓平臺自動去處理，不用人工干預，也可以配置成定時任務去執行，比如一些需要在夜間時進行的版本發布，這樣就會輕松許多。現在我們將一些備份的任務也放到這個平臺上面來執行，每天會定時執行并發送執行結果郵件通知。

三、實時監控、持續優化

通過以上敏捷迭代可以在很大程度上能提高生產環境下的代碼的質量，避免出現一些Bug。但是凡事都有意外，所以對于生產環境正在運行的業務，做好持續的監控很重要。

唔哩除了使用zabbix監控CPU、內存、磁盤IO、網絡流量IO、進程/端口、TCP連接、日志以及中間件運行狀態參數外，還使用了聽云的APM監控技術。唔哩運維總監認為：“雖然商業產品需要成本，但是商業產品可以提供完備的服務，總比自已花時間慢慢研究來的直接有效，對于創業公司來說時間成本是巨大的，產品的快速發展需要良好的用戶體驗，APM的價值對于用戶來說促進作用非常大，否則因為產品不穩定導致用戶流失損失比成本更大。”

聽云APM使用了大數據技術，可以定位分析到每一次函數調用具體情況。以下示例為唔哩Server端監控圖例說明：

唔哩攜手聽云APM：敏捷運維提升產品質量

上圖中是對一個登陸的過程進行的分析，點擊“web應用過程”，可以查看耗時百分比，響應時間，吞吐率，錯誤率等。選擇“響應時間”左邊一欄顯示的接口調用及平均響應時間，右側顯示為具體的分解圖表信息，可以看到userparter/SELECT這個操作圖形占比最高，峰值近500ms，在表格中也可以看到是mysql操作，耗時占比96%，調用次數37,平均響應時間為184ms。有了這些數據信息，如果出現異常就可以快速定位到具體原因，而且對于產品的持續優化也有參考依據。

除了Server端，移動端和網絡也使用了聽云做了監控。通過聽云App對唔哩APP的監控可以很容易查看客戶端崩潰、網絡請求、劫持分析、錯誤等。使用聽云Network對網絡的監控是因為聽云能提供用戶端的節點探測，比IDC節點監控更接近真實用戶的網絡環境。

敏捷運維是一種思想，是讓軟件開發、測試、運維之間建立起溝通協作關系，加強角色間信息互換和共享，統一流程和規范，最終實現運維自動化，共同保證產品的質量。