摘要：關(guān)注的目標就是在代碼提交之后，順利且迅速的把新的功能部署到產(chǎn)品環(huán)境上。由于是，那么單元測試，回歸測試，集成測試，都是實現(xiàn)的手段。高質(zhì)量的產(chǎn)品需求書和高質(zhì)量的自動化集成測試用例毫無疑問，是高質(zhì)量軟件的保證之一。

Test-Driven Development 測試驅(qū)動開發(fā)，這個詞兒各位技術(shù)大大必定耳熟能詳，我作為一個曾經(jīng)的Develop, ops,現(xiàn)在的DevOps從業(yè)者，這次想來跟大家聊聊Test-Driven Development。測試驅(qū)動開發(fā)傳統(tǒng)意義上就是先寫測試用例，再做代碼實現(xiàn)，這樣就能明確代碼功能，減少開發(fā)無用功能的時間，很多好處，就不贅述了。

下面聊聊我想要說的TDD。
DevOps這一位置是互聯(lián)網(wǎng)產(chǎn)品逐漸成熟之后，為了滿足互聯(lián)網(wǎng)開發(fā)&發(fā)布周期的特點所提出的一個新的崗位要求。關(guān)注的目標就是在代碼提交之后，順利且迅速的把新的功能部署到產(chǎn)品環(huán)境上。

其實這是一個很寬泛，涵蓋內(nèi)容比較多的話題，但是重中之重，顯然是在于代碼質(zhì)量。所以我們內(nèi)部提出的測試驅(qū)動開發(fā)，意義不僅僅在于單元測試用例先于開發(fā)代碼之前的編寫，而在與通過真正的測試報告來推動代碼的Bug修復。所以應該是Test-Driven Debug。由于是Test-Driven Debug，那么單元測試，回歸測試，集成測試，都是實現(xiàn)TDD的手段。

在整個DevOps的流程的上游，就是探究如何把這一系列的測試及時的反饋給Develop以幫助其改進代碼質(zhì)量。

測試用例的編寫是非常重要的，我們的最終目標是PM寫出產(chǎn)品需求之后，測試人員能夠和開發(fā)人員一同進入編碼流程，開發(fā)人員進行代碼編寫的同時測試人員進行自動化集成測試用例的編寫。這對測試開發(fā)人員和PM都提出比較高的要求，一是PM提出的需求能夠足夠詳細到最終功能的描述，其次要求測試人員能夠僅根據(jù)功能描述完成測試用例的編寫。這樣同時進行的功能編寫和功能測試還能促進PM的需求文檔進一步的完善。

高質(zhì)量的產(chǎn)品需求書和高質(zhì)量的自動化集成測試用例毫無疑問，是高質(zhì)量軟件的保證之一。

其次，作為DevOps的職責之一，就是怎么把這個過程流轉(zhuǎn)起來，規(guī)范化，形成固定的軟件發(fā)布過程。

我們在內(nèi)部搭建了一套即插即用的軟件測試流轉(zhuǎn)平臺，整套流程使用的是Jenkins+Docker 的實現(xiàn)方式，Jenkins是標準的配置管理工具，有非常豐富的插件。Docker的優(yōu)勢在于隨用隨部署，并且能夠把不支持rest接口的工具做成支持rest 接口的工作方式，再加上Jenkins本身就支持rest接口，這樣我們在部署整套系統(tǒng)的過程中，就不需要依賴目錄/文件共享的方式，全部使用rest協(xié)議，為Jenkins之間的job實現(xiàn)了解耦。
我們先看下構(gòu)成圖：

圖畫的不好，請諒解...

整個環(huán)節(jié)大致如下：

Develop push 代碼到代碼庫。

代碼庫用hook 觸發(fā)Jenkins 啟動。

Jenkins調(diào)用Checkstyle,Pmd等測試job，測試參數(shù)從report pool獲取，最終產(chǎn)生的report存入report pool。

產(chǎn)生報告，需要的報告內(nèi)容全部從report pool中獲取。

發(fā)送郵件報告。

report pool暫時使用Elastic search充任，不僅作為report的報告池，還中轉(zhuǎn)了一些必要的配置文件，譬如規(guī)則文件等。

sendmail是必須的，每次測試結(jié)束之后發(fā)送的郵件是push Develop的唯一手段，也就是說，這個step是整個項目的臉面，有沒有效果全看sendmail做的是不是夠“觸目驚心”了。

我們要求所有的Develop每天必須定時檢查郵件，來獲知測試結(jié)果，在項目后期必須當天解決bug，如果有任何延時必須上報pm以進行資源調(diào)配，以保證項目按時發(fā)布高質(zhì)量的代碼。

于此同時，將配備一個SPL去trigger并且push這一過程，給項目按時發(fā)布配備雙重保證。

那么Docker是如何使用到這套環(huán)境中的呢？
譬如本例中的heckstyle, 這是最普遍的java代碼風格檢查工具，執(zhí)行命令如下：

java -jar /root/checkstyle-xxx.jar -c rule.xml -f xml /var/jenkins/src -o /root/result.xml

很簡單一個命令，按照rule.xml定義的代碼規(guī)范，對/var/jenkins/src目錄下的源代碼進行掃描，輸出的結(jié)果寫入/root/result.xml中。

在使用Docker之前，我們的做法是Jenkins 的一個job checkout代碼，然后在shell script 執(zhí)行這條java命令，把輸出的result.xml做為發(fā)布文件，給之后Jenkins的Checkstyle做為輸入，并生成Checkstyle的summary report，這兩個項目必須指定一個能共享的文件目錄，以便信息交換，明顯制約了項目部署。

這種做法在Docker出現(xiàn)之前，幾乎是唯一的實現(xiàn)方式。在用了Docker之后，我們看看會怎么做這個測試工作。

代碼的checkout

獲取rule.xml

運行Checkstyle

把生成的Checkstyle的report上傳到report pool

以上四項操作都集成在docker里面，做成image.

Jenkins所要做的就是調(diào)用docker api接口，兩條命令:

curl -l –H xxxxxxxxxx http://server:port/containers/create?name=checkstyle
curl -X POST http://server:port/containers/checkstyle/start

完了之后，checkstyle產(chǎn)生的report就會進入report pool。

獲取 report:

curl -XGET http://server:port/checkstyle/reports/checkstyle_report.xml

生成Checkstyle 的 Trend graph。

這樣操作的優(yōu)點是顯而易見的。

Jenkins 的各項工具之間充分解耦，可以隨時部署隨時使用，不局限在某一個物理設(shè)備上

Docker做的標準工具，可以迅速的部署一套符合需求的測試流程

添加新的Jenkins工具不需要在Jenkins主機上安裝各種工具，破壞原有的結(jié)構(gòu)，使用Docker的rest api可以輕松的實現(xiàn)各種工具的即插即用。

配置管理過程中使用Docker的優(yōu)勢還有很多，我這里只述及了很小的一部分。

在需要快速開發(fā)的互聯(lián)網(wǎng)時代，如何快速搭建一套軟件質(zhì)量保證的環(huán)境也是面臨的挑戰(zhàn)之一，通過Jenkins和Docker，我們能夠迅速搭建一套符合要求的測試流程，并給提供給Develop及時的反饋，推進Develop對bug的Fix，提高Bug fix率從而提高代碼質(zhì)量。

有了這套系統(tǒng)，連接Develop和Tester，相信能更好的push 軟件代碼質(zhì)量的提高，從而為快速部署和快速發(fā)布，為整個DevOps的流程打下堅實的基礎(chǔ)。

原文作者來自 MaxLeap 團隊_Service&Infra 成員：Kevin
原文鏈接：https://blog.maxleap.cn/archives/719

歡迎關(guān)注微信訂閱號：從移動到云端
歡迎加入我們的MaxLeap活動qq群：555973817，我們將不定期做技術(shù)分享活動。