理想中的Jenkins+Sonar+Github代碼質量管理

背景

前陣子老美的Audit要求各個開發組截圖各自repository的Sonar Analysis Report，我跑去Sonarqube一看。。。好傢伙！全是紅燈，簡直慘不忍睹

固然這其中有歷史問題，由於咱們是半路接管的歐美team的code，不少issue都是old code所遺留的。

不逃避責任，其中也有一部分是咱們後續提交的新代碼形成的，經過項目2年來的日積月累，issue多的有點積重難返，sonarqube雖然在每次jenkins build都會生成report，可是咱們卻沒有把它做爲build成功失敗的一個硬指標。只要build成功經過QA測試就行了嘛！管他孃的sonar quality gate

結果

爲了出一份體面漂亮的report給audit，我不得不馬不停蹄的checkout -b quick_fix_sonar_issues, 花了一成天的功夫把block和critical的issue降到了閾值如下。

臨陣磨槍的我體會到了如下3個痛點

1. 不少Sonar能檢測出來的issue，在人工code review GitHub PR的時候其實很難被發現
2. 有些同事在code中犯的錯誤真的很低級，可是人工code review中很難被發現，不是個人鍋，我如今卻在爲同事擦屁股。
3. 雖然快速fix了issue，可是code的owner並非我，我有可能爲了迎合sonar的rule而產生了潛在的新的issue，而和owner去一一check又增長了不少溝通成本，另外owner頗有可能已經離職了

思考

囧則思變！如何改進咱們的開發流程？在代碼開發階段就能讓Sonar分析出問題？強制owner必須解決完issue才能提交代碼？嗯！是時候對目前存在弊端的開發流程進行改進了！

老的開發流程

先介紹下目前的基礎設施：

• 經過GitHub來管理source
• 經過Github Pull Request來實現Code Review（之前用gerrit可是我以UI太醜爲由號召開發們拒絕使用）
• 經過Jenkins來實現持續集成
• 經過Sonarqube來實現代碼分析（形同虛設）

老的流程：

1. 當一個新feature來臨時
2. owner從master（受保護的）分支checkout 一個feature_dev_branch作開發
3. 開發完成後，提交pull request（PR）請求合併到master
4. 技術leader對PR進行code review並approve後，feature_dev_branch合併到master。
5. Merge觸發觸發Jenkins自動build，Jenkins觸發Sonarqube scan產生report（僅僅生成report）
6. Build成功則進行package的deploy以及後續Automation Testing等流程
7. 交付QA測試

改進後的開發流程：

1. 當一個新feature來臨時
2. owner從master （受保護的）分支checkout 一個feature_dev_branch作開發
3. 開發完成後，提交pull request（PR）請求合併到master
4. PR自動觸發Jenkins，Jenkins觸發Sonar分析本次提交的new code
5. Sonar將report和issue以comments的方式寫到Github PR裏，並做爲硬性的check point
6. Owner對PR進行反覆commit直至經過Sonar的分析
7. 技術leader對PR進行code review並approve後，feature_dev_branch合併到master。
8. Merge觸發觸發Jenkins自動build，Jenkins觸發Sonarqube scan產生report（僅僅生成report）
9. Build成功則進行package的deploy以及後續Automation Testing等流程
10. 交付QA測試

加了3步，使得new code經過sonar檢測成爲一個硬性指標，把issue扼殺在萌芽中，把鍋甩在最前面

哇！！！太Cool了！

跟我一步步完成Jenkins和Sonar的配置

什麼？你居然不知道Jenkins是個啥？！那你操個哪門子的心去優化開發流程，好好搬你的磚，寫你的bug！咳咳！建議你轉發本文給負責devops的同事，請他吃飯讓他幫忙配置

Jenkins須要一個plugin，叫作github pull request builder

它的做用是生成在Jenkins和Github之間生成webhook，似的PR能夠自動觸發Jenkins的Build

稍微配置下這個插件，畫紅線的地方很重要

Jenkins還須要一個plugin，叫作SonarQube Scanner

它的做用是讓Jenkins去觸發Sonar的分析

稍微配置下這個插件，畫紅線的地方很重要

沒據說的Sonar？沒有現成的Sonar Server? 額，繼續請devops吃飯吧...

Sonarqube裏（注意是Sonarqube裏，不是Jenkins裏）也須要安裝一個plugin，名字叫 Github

它的做用是 當Sonar檢測完畢後，把生成的report和issue的分析以comments的方式寫回到Github的PR中

稍微配置下這個插件，畫紅線的地方很重要

接下去就是配置Jenkins的project了

廢話很少，只貼關鍵配置，紅線部分很重要

Advanced裏能夠勾上這一條（雖然是Dangerous），由於咱們Github是企業版，因此能提PR的人是有權限控制的，若是是用官網的github管理代碼請慎用這個選項，建議使用黑白名單來控制觸發的條件。

如下是Sonar的配置，很重要，注意analysis mode只能選擇preview，preview mode不會真正的在Sonar上生成report哦。

寫在最後

Jenkins的安裝，Sonar的安裝啥的，教程我就不放link了，這種大路教程一搜一大堆（我我的建議你用docker安裝）做爲一個開發，我以爲這些基本的，能提高工做效率的工具仍是要掌握一下的，並非說只有devops纔會用到這些工具，誰不喜歡偷懶呢，這些都是偷懶的好幫手。

截止發稿時，這個流程還存在一些些小bug，好比preview mode的sonar分析不能跟sonar中quality gate進行結合，sonar js不能分析parse有問題的js文件等等，還顯得不夠完美，咱們也在經過其它的workaround來100%實現理想中的開發流程，若是你有好的建議歡迎留言。