快速部署TEST-DRIVEN DEVELOPMENT/DEBUG環境

什麼是Test-Driven Development

Test-Driven Development 測試驅動開發，這個詞兒各位技術大大一定耳熟能詳，我做爲一個曾經的Develop, ops,如今的DevOps從業者，此次想來跟你們聊聊Test-Driven Development。測試驅動開發傳統意義上就是先寫測試用例，再作代碼實現，這樣就能明確代碼功能，減小開發無用功能的時間，不少好處，就不贅述了。

什麼是Test-Driven Debug

下面聊聊我想要說的TDD。
DevOps這一位置是互聯網產品逐漸成熟以後，爲了知足互聯網開發&發佈週期的特色所提出的一個新的崗位要求。關注的目標就是在代碼提交以後，順利且迅速的把新的功能部署到產品環境上。

其實這是一個很寬泛，涵蓋內容比較多的話題，可是重中之重，顯然是在於代碼質量。因此咱們內部提出的測試驅動開發，意義不只僅在於單元測試用例先於開發代碼以前的編寫，而在與經過真正的測試報告來推進代碼的Bug修復。因此應該是Test-Driven Debug。因爲是Test-Driven Debug，那麼單元測試，迴歸測試，集成測試，都是實現TDD的手段。

TDD和DevOps的關係

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

測試用例的編寫是很是重要的，咱們的最終目標是PM寫出產品需求以後，測試人員可以和開發人員一同進入編碼流程，開發人員進行代碼編寫的同時測試人員進行自動化集成測試用例的編寫。這對測試開發人員和PM都提出比較高的要求，一是PM提出的需求可以足夠詳細到最終功能的描述，其次要求測試人員可以僅根據功能描述完成測試用例的編寫。這樣同時進行的功能編寫和功能測試還能促進PM的需求文檔進一步的完善。

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

其次，做爲DevOps的職責之一，就是怎麼把這個過程流轉起來，規範化，造成固定的軟件發佈過程。

Jenkins & Docker 快速部署 TDD

咱們在內部搭建了一套即插即用的軟件測試流轉平臺，整套流程使用的是Jenkins+Docker 的實現方式，Jenkins是標準的配置管理工具，有很是豐富的插件。Docker的優點在於隨用隨部署，而且可以把不支持rest接口的工具作成支持rest 接口的工做方式，再加上Jenkins自己就支持rest接口，這樣咱們在部署整套系統的過程當中，就不須要依賴目錄/文件共享的方式，所有使用rest協議，爲Jenkins之間的job實現瞭解耦。
咱們先看下構成圖：

圖畫的很差，請諒解...

整個環節大體以下：

1. Develop push 代碼到代碼庫。

2. 代碼庫用hook 觸發Jenkins 啓動。

3. Jenkins調用Checkstyle,Pmd等測試job，測試參數從report pool獲取，最終產生的report存入report pool。

4. 產生報告，須要的報告內容所有從report pool中獲取。

5. 發送郵件報告。

report pool暫時使用Elastic search充任，不只做爲report的報告池，還中轉了一些必要的配置文件，譬如規則文件等。

sendmail是必須的，每次測試結束以後發送的郵件是push Develop的惟一手段，也就是說，這個step是整個項目的臉面，有沒有效果全看sendmail作的是否是夠「觸目驚心」了。

咱們要求全部的Develop天天必須定時檢查郵件，來獲知測試結果，在項目後期必須當天解決bug，若是有任何延時必須上報pm以進行資源調配，以保證項目按時發佈高質量的代碼。

於此同時，將配備一個SPL去trigger而且push這一過程，給項目按時發佈配備雙重保證。

那麼Docker是如何使用到這套環境中的呢？
譬如本例中的heckstyle, 這是最廣泛的java代碼風格檢查工具，執行命令以下：

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

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

在使用Docker以前，咱們的作法是Jenkins 的一個job checkout代碼，而後在shell script 執行這條java命令，把輸出的result.xml作爲發佈文件，給以後Jenkins的Checkstyle作爲輸入，並生成Checkstyle的summary report，這兩個項目必須指定一個能共享的文件目錄，以便信息交換，明顯制約了項目部署。

這種作法在Docker出現以前，幾乎是惟一的實現方式。在用了Docker以後，咱們看看會怎麼作這個測試工做。

1. 代碼的checkout

2. 獲取rule.xml

3. 運行Checkstyle

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

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

Jenkins所要作的就是調用docker api接口，兩條命令:

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

完了以後，checkstyle產生的report就會進入report pool。

獲取 report:

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

生成Checkstyle 的 Trend graph。

這樣操做的優勢是顯而易見的。

1. Jenkins 的各項工具之間充分解耦，能夠隨時部署隨時使用，不侷限在某一個物理設備上

2. Docker作的標準工具，能夠迅速的部署一套符合需求的測試流程

3. 添加新的Jenkins工具不須要在Jenkins主機上安裝各類工具，破壞原有的結構，使用Docker的rest api能夠輕鬆的實現各類工具的即插即用。

配置管理過程當中使用Docker的優點還有不少，我這裏只述及了很小的一部分。

在須要快速開發的互聯網時代，如何快速搭建一套軟件質量保證的環境也是面臨的挑戰之一，經過Jenkins和Docker，咱們可以迅速搭建一套符合要求的測試流程，並給提供給Develop及時的反饋，推動Develop對bug的Fix，提升Bug fix率從而提升代碼質量。

有了這套系統，鏈接Develop和Tester，相信能更好的push 軟件代碼質量的提升，從而爲快速部署和快速發佈，爲整個DevOps的流程打下堅實的基礎。

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

歡迎關注微信訂閱號：從移動到雲端歡迎加入咱們的MaxLeap活動qq羣：555973817，咱們將不按期作技術分享活動。