[[164891]]

　　現(xiàn)今，人們的生活習(xí)慣發(fā)生了翻天覆地的變化，一邊在高呼擁抱互聯(lián)網(wǎng)，一邊又在痛斥它給人們帶來(lái)便捷生活的時(shí)候自己沒(méi)有趕上創(chuàng)業(yè)潮流，中國(guó)人的人群效應(yīng)恰巧對(duì)應(yīng)了這點(diǎn)：“我看不慣你，又干不掉你”，***就只能臣服于互聯(lián)網(wǎng)的驅(qū)動(dòng)下。默默收起淚眼婆娑的羨慕，轉(zhuǎn)戰(zhàn)這個(gè)怪圈。傳統(tǒng)的IT部署依然滿(mǎn)足不了這個(gè)時(shí)代的需求，云計(jì)算的出現(xiàn)，更使得企業(yè)轉(zhuǎn)型迫在眉睫。

　　新致云開(kāi)發(fā)團(tuán)隊(duì)順應(yīng)自動(dòng)化的時(shí)代潮流，結(jié)合敏捷開(kāi)發(fā)、持續(xù)集成、持續(xù)部署等先進(jìn)理論在團(tuán)隊(duì)協(xié)作領(lǐng)域掀起了全新的自動(dòng)化浪潮。早期新致云項(xiàng)目組的團(tuán)隊(duì)協(xié)作依賴(lài)于較多的人工操作，而人工操作的缺點(diǎn)顯而易見(jiàn)，溝通信息的失真、重復(fù)繁瑣的勞動(dòng)都造成了大量時(shí)間成本的浪費(fèi)以及作業(yè)效率的降低。引入自動(dòng)持續(xù)集成的概念后，開(kāi)發(fā)和測(cè)試人員可以解放大量的人力勞動(dòng)。不僅使得代碼的質(zhì)量可以得到更好的保障，在部署和監(jiān)控方面也可以做到更加人性化和可視化。本編著重探討持續(xù)集成中自動(dòng)化代碼質(zhì)量檢測(cè)。

　　代碼質(zhì)量門(mén)——SonarQube

　　試想一下：一個(gè)開(kāi)發(fā)團(tuán)隊(duì)如何在人員持續(xù)流動(dòng)且不穩(wěn)定的情況下，快速交接現(xiàn)有代碼?如何保證寫(xiě)下的代碼沒(méi)有潛在的問(wèn)題和技術(shù)債務(wù)?顯然，良好的代碼規(guī)范和質(zhì)量審查必不可少。SonarQube是一款優(yōu)秀的開(kāi)源代碼管理平臺(tái)，可以進(jìn)行持續(xù)的代碼分析和代碼質(zhì)量檢測(cè)，幫助開(kāi)發(fā)人員發(fā)現(xiàn)邏輯問(wèn)題之外的技術(shù)BUG和潛在的隱患。

　　除此之外，自動(dòng)化則將SonarQube的分析過(guò)程以自動(dòng)化的方式執(zhí)行，同時(shí)依托Jenkins自動(dòng)化服務(wù)管理，使得我們可以針對(duì)開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)出一整套代碼測(cè)試與質(zhì)量分析的產(chǎn)品。使用者完全不必關(guān)心測(cè)試環(huán)節(jié)的具體過(guò)程和繁瑣的配置，只需要關(guān)心測(cè)試的結(jié)果即可。

　　基于這種情況，自動(dòng)化集成在團(tuán)隊(duì)敏捷開(kāi)發(fā)的要求下顯得尤為重要，開(kāi)發(fā)人員每天都要交付功能代碼以響應(yīng)快速迭代的需求，若代碼質(zhì)量完全依靠人工則會(huì)使得工作量過(guò)于龐大，造成開(kāi)發(fā)壓力，如果使用這一套自動(dòng)化流程可以大幅提高開(kāi)發(fā)人員的交付能力。

　　工作環(huán)境：

　　以分布式版本控制的工作模型為例，項(xiàng)目代碼由中央和分支倉(cāng)庫(kù)管理。中央倉(cāng)庫(kù)由項(xiàng)目擁有者維護(hù)，開(kāi)發(fā)者拷貝中央倉(cāng)庫(kù)并創(chuàng)建自己的個(gè)人分支，在個(gè)人分支上進(jìn)行工作，階段工作完成之后向開(kāi)發(fā)分支(假如叫做dev分支)中央庫(kù)以Pull Request的方式合并代碼。

　　Pull Request(PR):

　　開(kāi)發(fā)人員請(qǐng)求代碼擁有者“pull”有變動(dòng)的代碼，代碼擁有者可以對(duì)貢獻(xiàn)的源碼進(jìn)行review，并決定是否合并到中央庫(kù)的主分支(在git中通常是master分支)。代碼開(kāi)發(fā)人員創(chuàng)建PR來(lái)通知項(xiàng)目擁有者代碼變更，有些服務(wù)如Github,Bitbucket,Gitlab提供了PR的評(píng)論功能。評(píng)論可以作為觸發(fā)測(cè)試的條件，也可以作為測(cè)試結(jié)果的展示。

　　說(shuō)了那么多的自動(dòng)化集成的工作，很多開(kāi)發(fā)工程師也許還在疑惑，我們現(xiàn)在的敏捷開(kāi)發(fā)已經(jīng)深入到各大行業(yè)，但是如何檢驗(yàn)所屬的工作環(huán)境是優(yōu)質(zhì)的呢?

　　工作流程：

　　依托Jenkins自動(dòng)化服務(wù)管理，開(kāi)發(fā)者可以在早晨上班時(shí)將代碼更新至dev分支的***提交，并在一天的開(kāi)發(fā)完成后在代碼管理工具Github,Bitbucket,Gitlab上創(chuàng)建PR，這個(gè)過(guò)程會(huì)觸發(fā)Jenkins的任務(wù)。該任務(wù)會(huì)拉取PR中源分支的***的代碼執(zhí)行編譯、單元測(cè)試以及代碼分析，之后發(fā)送報(bào)告郵件給代碼提交者和代碼擁有者，并且將Jenkins的構(gòu)建結(jié)果作為一條評(píng)論創(chuàng)建到PR中，代碼擁有者來(lái)決定是否合并。

　　操作流程(以Stash為例)：

　　插件：

　　1.stash中需要安裝Bitbucket Server Webhook for Jenkins插件。用于在代碼提交之后觸發(fā)Jenkins Job的構(gòu)建操作。

　　2.Jenkins中需要安裝SonarQube Plugin。用于在代碼構(gòu)建之后進(jìn)行分析。

　　3.Jenkins中安裝Stash pullrequest builder plugin。用于監(jiān)聽(tīng)pull-request中源分支的變化，并構(gòu)建該分支。

　　步驟

　　1. 在Jenkins中建立兩個(gè)job，一個(gè)是構(gòu)建job，另一個(gè)是郵件Job。

　　2. 配置Stash pullrequest builder plugin。實(shí)現(xiàn)當(dāng)pull-request中的源分支發(fā)生變化(有代碼提交)時(shí)，Jenkins自動(dòng)觸發(fā)該build。

　　3. Build流程：在buildjob中拉取代碼。通過(guò)git命令獲得代碼提交者的郵件，提交時(shí)間等。存入公共文件。文件規(guī)則可以自行擬定。(遇到Jenkins存在節(jié)點(diǎn)的情況，可以使用NFS掛載的方式實(shí)現(xiàn)文件共享。)

　　4. build項(xiàng)目，并使用SonarQube進(jìn)行代碼分析。分析結(jié)果會(huì)輸出在Jenkins控制臺(tái)。

　　5. 在emailjob中，讀取公共配置文件。讀取收件人信息，郵件標(biāo)題，Jenkins任務(wù)名，構(gòu)建號(hào)等。通過(guò)Jenkins CLI讀取上一步中控制臺(tái)的內(nèi)容，提取相關(guān)信息作為郵件正文。

　　6. 發(fā)送郵件。

　　7. jenkins向stash返回構(gòu)建結(jié)果和連接，作為pull-request的一條評(píng)論，供leader審核。由leader審核代碼并決定是否合并代碼。

 

　　總的來(lái)說(shuō)，在項(xiàng)目中，開(kāi)發(fā)人員會(huì)遇到各種各樣的問(wèn)題，自動(dòng)化集成在項(xiàng)目開(kāi)發(fā)中和應(yīng)用中越來(lái)越重要，既減輕了開(kāi)發(fā)難度，又提高了項(xiàng)目交付能力，從產(chǎn)品需求出發(fā)，利用自動(dòng)化管理流程，使得敏捷開(kāi)發(fā)優(yōu)勢(shì)***化。