持續整合(CI)、自動化構建和自動化測試--初探 .
此文章是為了總結前一段時間由於Maven2的學習而引起的一個持續整合的學習。
一、什麼是持續整合(Continuous Integration)?
這個概念到底是怎麼定義,說實話很多不同的版本。這裡我就把我理解的什麼叫持續整合說下,其實持續整合是為了配合敏捷開發的速度和效率而產生的一個用於編譯、測試、釋出、部署的工具。為什麼叫持續呢?其實就是編碼人員提交了原始碼,那麼該工具就可以進行編譯,測試等一系列運作。怎麼能夠讓編碼人員很快的知道編碼的異常。
二、工具的選擇 :Maven2、 Hudson(CruiseControl可以考慮)、SVN
首先我們來看看這個環境是怎麼運作的吧! 編碼人員將程式碼提交到SVN,那麼Hudson就監控到SVN有更新,那麼Hudson就去SVN取出更新的原始碼。取出後就交給Maven去編譯、測試、釋出等操作。
一、什麼是持續整合(Continuous Integration)?
這個名詞已經在軟體開發領域持續了N年,一個比較簡單的定義如下:
持續整合(CI)是一種實踐,可以讓團隊在持續的基礎 上收到反饋並進行改進,不必等到開發週期後期才尋找和修復缺陷。
通俗一點兒說:
就是指對於開發人員的每一次程式碼提交,都自動地把Repository中所有程式碼Check out到一個空目錄,並且自動執行所有Test Case。如果成功則接受這次提交,否則告訴所有人,這是一個失敗的Revision。
更具體的解釋可以參考Martin fowler的Continuous Integration 。
二、持續整合的價值與成本
有句時髦的話,叫做“存在即為合理”。既然持續整合已經存在了這麼長的時間,而且沒有消失的跡象,那就是有價值的東西。
那麼它的價值何在?有人概括如下:
(1) 減小風險;(2) 減少手動過程;(3) 生成構建結果;(4) 安全感。
而持續整合的成本在於對持續整合程式碼的維護成本和整合的時間成本。因為隨著專案進行,軟硬體環境會越來越複雜,成品程式碼也會不斷膨脹。此時,需要團隊而修改或增加原有的測試程式碼,以適應這些變化,同時,每次整合所需時間也會變長,這就是持續整合的成本。
某個blog中提道:“這種整合是如此的頻繁,多少次的程式碼Commit就有多少次持續整合。前提是整合的成本很低,或者說是完全自動化的。”
三、持續整合應該自動化什麼呢?
我們要以儘可能少的成本來獲得儘可能多的價值。這就要考慮哪些自動化是必要的啦。
Jez Humble提到至少有六點要做到自動化,
它們分別是(1)自動化的執行測試;
(2) 自動產生可部署的二進位制成品;
(3) 自動將成品自動部署到近似生產環境;
(4) 自動為CodeBase打上標籤;
(5) 自動執行迴歸測試;
(6)自動生成度量報告。
四、持續整合伺服器的選擇
在進行持續整合實踐前,應當正確的選擇並配置持續整合伺服器。比較成熟的持續整合伺服器包括:CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作為開源產品,以其對於各種SCM(原始碼管理,製造業上是供應鏈關係管理)以及構建工具的廣泛支援而被許多開發團隊所接受。而開發自動化專家 Duvall 採用一致的評估標準和很多說明性示例,介紹了一些開源 CI 伺服器,包括 Continuum、CruiseControl 和 Luntbuild。並指出“要根據 自己的 具體技術和政策需求對工具進行分析”。並用以下五個指標來評估CI工具,它們分別是:(1) 特性;(2) 可靠性;(3) 壽命;(4) 目標環境;(5) 易用性。結果如下表:
而CruiseControl是我唯一真正用過的持續整合工具,它現在靈活而又強大功能也讓我瞠目,而且配置與管理也較兩年前容易得多啦。
為什麼說它強大呢?因為你只要想得到的問題,它也都會有所考慮。朋友的Blog上有些CruiseControl的最佳實踐足以證明這一點,只要你肯去實踐。
五、只有持續整合伺服器是遠遠不夠的
正如Jez Humble所說,CruiseControl和其它的CI工具本質上只不過是一個定時器,時間一到,做你讓它做的事情。所以,必然要有其它工具與其結合,方顯持續整合的本色。這些工具又是什麼呢?
想測試的話,你就要用一些測試工具,如JUnit,JWebUnit,Selenium等等;
想檢查程式碼標準的話,你就要用checkstyle等程式碼規範檢查工具;
想要了解測試覆蓋率的話,你可能就要用到JCoverage啦。
當然,想得到二進位制檔案,就要用到Ant,Make之類的工具啦。
六、最重要的事:實踐與反思
也許這些東西大家都知道,而且有些人可能已經實踐過啦。無論這些實踐的結果是怎樣的,一定不要忘記總結和反思。如果這些實踐成功了,不要把它歸功於這個工具,而是要總結一下為什麼會成功,如果你願意的話,還可以和大家分享一下。如果這些實踐失敗了,也不要把它歸功於這個工具,而是要反思一下,是否正確地使用了這個工具,團隊成員是否都喜歡這個工具,為什麼?
相關文章
- 使用 flow.ci 實現 Android 自動化測試與持續整合Android
- SoapUI實踐:自動化測試、壓力測試、持續整合UI
- 思考如何將自動化測試加入持續整合中
- 新夢想幹貨分享——持續整合的自動化測試
- 知物由學 | SDK API自動化測試與持續整合API
- 用 Travis CI 打造大前端持續整合和自動化部署前端
- 前端自動化測試初探(一)前端
- Jenkins+Python自動化測試持續整合詳細教程JenkinsPython
- jenkins+ant+jmeter介面自動化的持續整合測試框架JenkinsJMeter框架
- 自動化專案Jenkins持續整合Jenkins
- jenkins介面、UI自動化持續整合JenkinsUI
- iOS 持續整合系列 - 自動化 Code ReviewiOSView
- iOS 持續整合系列 – 自動化 Code ReviewiOSView
- 基於 flow.ci 實現 PHP 專案自動化持續整合PHP
- CI Weekly #11 | 微服務場景下的自動化測試與持續部署微服務
- ET-ci — 全自動軟體測試排程(持續整合)平臺
- UI自動化測試框架Cypress初探UI框架
- Puppeteer 初探之前端自動化測試前端
- 自動化測試系列 —— UI自動化測試UI
- 【自動化測試入門】自動化測試思維
- 「持續整合實踐系列 」Jenkins 2.x 構建CI自動化流水線常見技巧Jenkins
- vuepress與travis-cli持續整合自動化部署Vue
- 持續測試跟自動化測試的這些區別你知道嗎?
- 自動化裝置測試與自動化測試的區別
- 自動化測試理解
- 自動化測試思路
- airTest自動化測試AI
- 介面自動化測試
- API自動化測試API
- 自動化測試框架框架
- 自動化元件測試元件
- 滴滴雲控制檯 Selenium 自動化測試初探
- Gitlab Runner實現NetCore自動化持續整合GitlabNetCore
- 測試開發之自動化篇-自動化測試框架設計框架
- flow.ci + Github + Slack 一步步搭建 Python 自動化持續整合GithubPython
- 利用tox打造自動自動化測試框架框架
- 構建高效的自動化測試框架框架
- JMeter 介面自動化測試(手工轉自動化指令碼)JMeter指令碼