Continuous integration

Software Development for Large and Open Source Projects

Kun‐Ta ChuangDepartment of Computer Science and Information Engineering

National Cheng Kung University

1

Agenda• 軟體自動化(Continuous Integration)流程簡介

– 為什麼需要軟體持續整合– 軟體開發情境模擬– CI的架構與範疇– CI通用原則

• 跟軟體開發流程工具結合– Version Control– Auto‐Build– Auto‐Testing

• CI範例介紹– CruiseControl安裝與使用– CruiseControl使用

• 完整實例展示• 結論

2






3

為什麼需要軟體持續整合技術• 「整合地獄」問題(Integration Hell)

– 團隊大型軟體開發時容易發生project delay，需求改變，schedule重排問題

– 這些問題通常會在不同系統元件整合時產生很嚴重的影響

• 軟體有可能會有多種版本for不同需求– 如何有效管理不同版本常是軟體獲利最關鍵點

4

為什麼需要軟體持續整合技術

• 如果每次都在開發後期才進行build– 一發生問題時難以進行錯誤追蹤及修改

• 應避免每次人工進行版本控制與軟體測試等動作

• 當程式碼或軟體開發人員一多，軟體品質的重覆性檢查變得極為重要但繁瑣

5


• Continuous Integration (CI) can help!– 降低風險

– 減少人工重複的程序

– 隨時可產生Deployable Software– 使專案的透明度

– 建立較好產品的信心

6


• 取代傳統上，開發完成後才進行品質控管，以提高軟體的品質，且降低執行時間。

• 容易在最短的時間內發現問題的存在。減少在整合時所出現的bug所花費的時間。

• Build software at every change

7

CI can help!

軟體開發情境模擬情境1• Ben : 我發現我的程式在local端可以跑，但是在

server端卻執行錯誤。

• John : 你有檢查你的code有發生錯誤嗎?

• Ben : 我已經完整check一遍了，且測試結果也都沒問題。

• John : 恩~我發現問題了，你的JDK是用舊的java版本，沒有更新。

• Ben : ....

8

軟體開發情境模擬情境1

• Solution 1– 可以使用可以判斷版本是否符合的build 軟體，

如Maven。

• Solution 2– 除了程式碼，也將專案用到相關檔案放進版本

控管容器。

9

軟體開發情境模擬情境II

• Ben : 你在做什麼?

• John : 我在等待最新程式碼上傳，因為之前程式碼有問題，還在修改中..

• Ben : 最新程式碼在兩天前已經上傳，你不知道嗎?

• John : 沒有耶!!當時我不在我的辦公室..

10

軟體開發情境模擬情境II

• Solution– CI server可以幫忙解決這類問題，每當專案

build fail，或者於版本控管容器有新的更新時，server便會自動寄電子郵件訊息給所有專案相關人員。

– 甚至也可加入SMS notification將文字訊息傳送到手機上面進行提醒。

11

軟體開發情境模擬情境III

• Ben : 我發現有一個程式上的bug，但是我查看近幾天程式更新的地方，似乎都沒發現到什麼問題..

• John : 那可能要追到更早以前的更新去檢查看看。

• Ben : ……….那不知道要檢查多久耶...

12

軟體開發情境模擬情境III

• Solution– 透過持續整合的機制，每當server偵測到容器

有更新時，系統便會自動進行build，及時將結果輸出。

– 一旦發現build失敗，有極大的機率是這次更新的地方發生問題或引發相關的衝突，便能盡早解決。

13

CI的架構與範疇

14Quoted from P. M. Duvall, et al., Continuous Integration: Improving Software Quality and Reducing Risk, 2007


• 版本控管（Version Control）• 測試自動化（Auto‐Testing）

• 建構自動化（Auto‐Build）

– 自動部署（Auto‐Deploy）

• 專案管理

• 錯誤通報及後續追蹤處理(Issue Tracker)機制的整合

15


• 你需要的整合工具– 需要一個程式的版本控管容器(git, svn…)– 自動建置工具(Ant, Maven…)– 測試自動化工具

• 還有CI平台– 各種檢查工具產生的分析結果，轉換成圖表、網頁、

存入資料庫– 將結果通知團隊成員，觀察趨勢，可與上一次分析結

果比較– 將多個專案用透明化且數據化的方式管理，呈現系統

即時品質，找出專案管理、系統設計、瑕疵追蹤等等重要的趨勢

16

CI通用原則

• 每天都要sync(check‐out)最新的程式碼

• 每天要提交一次程式碼check‐in• 個人程式碼check‐in原則

– 由主分支拉出一個分支(personal workspace)– 由此分支進行修改並且測試

– 測試成功後再與主分支同步(其他人的修改也可以update)，並且在進行測試與修改

– 上傳到主分支，同樣進行測試與修改

– 如果要新增功能則在重頭開始以上的步驟

17

CI通用原則

18

• 團隊共識– 不能也不會從版本控制容器get到不能執行的程式

• 只要get下來就應該要可以build，如果不能build ，應該是自已環境的問題

– 如果測試失敗，每個成員都會知道，並可在最短時間內修復

– 降低工程師自行撰寫測試程式的門檻，由工程師自行做第一關的軟體測試方能把關

– 新程式碼必須通過品質的指標門檻與測試結果才可以check‐in

– 團隊每個人均有良好的check‐in、check‐out、private build習慣

• 如”程式碼的衝突必須先行解決(resolve)方能check‐in”• 如”不在下班前一小時才check‐in程式碼”

CI通用原則

• Build機制– (1) On-demand : 由使用者驅動之程序，主要由使用

者初始化整合build。– (2) Schedule : 由時間來驅動，固定一段時間執行一

次build。– (3) Poll for changes : 每隔一段時間檢查是否有更改，

如有則執行build。– (4) Event-driven : 由某件事件驅動build，比如說 : 當

重新定義事件發生，則執行build。

Build Type Build 機制

Private (1)

Integration (1)(2)(3)(4)

Release (1)(2) 19

CI通用原則

• 時常觀察專案健康度 (Hudson)

直接由Hudson以圖表方式檢視程式test結果

20http://www.peterfranza.com/2008/09/26/comparison‐of‐continuous‐integration‐servers/

CI通用原則

檢視程式狀態與測試結果

時常觀察專案健康度 (Jenkins)

21https://builds.apache.org/

CI通用原則

可觀察所有人是否有建置

時常觀察專案健康度 (Jenkins)

22






23

軟體開發工具整合

• 版本控管 (Version Control)– 必備三元素

• 保留修訂記錄。

• 連結性。

• 不可分割的交易。

– Famous Version Control System( VCS)

• git• Mercurial• subversion(svn)• cvs• perforce

24


25

版本控管工具‐git◦ 清楚了解每個開發者送交歷

史紀錄


26

版本控管工具

◦ Demonstration from Mozilla

http://hg.mozilla.org/mozilla‐central/graph


27

版本控管工具

◦ 容易比較與原先版本的差異


• 自動建置(Auto‐Build)– 什麼是建置 ‐ 包含編譯(compile)、測試(testing)、

檢查(inspection)、佈署(deployment)等等動作。

– 自動建置機制

• 撰寫build script，系統會依此自動的建置專案

• 常見的自動建置工具

– gmake/icecream– Avanced build tools (XML‐based build script)

• Ant/Maven (Project Object Model)

28


• Ant

Ant已將程式編譯，產生執行檔以及執行的動作，自動化執行29


• Maven只需要一行就可以完成編譯&測試

30


• 軟體測試– 單元測試 (Unit Testing)– 元件測試 (Component Testing)– 系統測試 (System Testing)– 功能測試 (Function Testing)– 壓力測試,回歸測試 (Regression Testing)– 整合測試 (Integration Testing)– Smoke Testing– …

• 用於維持軟體可靠度

31


• 單元測試：基本且細部測試，測試每一單元(一個method或class)，常見的如JUnit。

• 元件測試：測試部分系統，如databases , file systems , network endpoints

32


• 系統測試：以系統模擬使用者使用此系統，常見的如:JWebUnit(測試網頁)

• 功能測試：以使用者角度，實際使用系統，如:Selenium

33


Test Packages

Test Suites

Test Cases

可觀察成功/錯誤/失敗

34


• assertEquals(expected value, actual value)

• JUnit使用此method測試程式碼產生的值是否與使用者所預期的值是否一致。

35


• 功能測試工具

– Selenium

錄製要測試的動作如果測試動作全完成就會呈現綠色 36






37

CI範例介紹

• CruiseControl– 為Open source 軟體，架設也較為容易。– 比較容易和第三方管理工具軟體整合。– 對於建構失敗時，系統傳送給使用者之資訊，比其

他CI軟體還要來的詳細

• 其它CI平台– Tinderbox: Perl‐based CI used in Mozilla products– Buildbot: Python‐based– Hudson: Java‐based– Jenkins: Java‐based– …

38

CI範例介紹

• 1. 到此網址下載cruisecontrol‐bin‐xxx 版本檔案。

39http://cruisecontrol.sourceforge.net/

CI範例介紹

• 2. 確認系統有安裝至少Java 1.4以上的版本。請注意CruiseControl是Java‐based Application:請指定JAVA_HOME變數。

40

CI範例介紹

• 3. 將於Step(1) 所下載的檔案解壓縮到想要的目錄，並執行cruisecontrol.bat。(可以發現裡面已經有Ant的build軟體)。

41

CI範例介紹

• 4. 到瀏覽器輸入http://localhost:8080/dashboard 可看到dashboard

42

CI範例介紹

• 4.1 (Error)沒安裝JDK的狀況

43

CI範例介紹

• 5. 查看build結果

44

CI範例介紹

• 6. 將特定程式故意改錯，一旦CI的build時間一到，並偵測到修改紀錄，便會進行build，以下為顯示錯誤之訊息。(目前將Cell.java其中一行code的冒號拿掉進行測試)

45

CI範例介紹

46

CI範例介紹

• 7. build 的test結果

47






48

完整實例展示

• Step1 . 撰寫一Sample code (in Java)

49

完整實例展示

• Step2 .撰寫測試用TestSuit

50

完整實例展示

• Step3. 撰寫ant建構用的xml檔

51

<<編譯的部分>>

<<測試的部分>>

完整實例展示

52

所有名稱Test結尾的類別檔都會進行測試

完整實例展示

• Step4. CI自動建置，產生結果(Correct)

53

完整實例展示

• 建置成功，測試比對不相符。

54

完整實例展示

• 建置失敗。

55

完整實例展示

56

建置失敗Email通知


– 為什麼需要軟體持續整合– 情境模擬– 軟體持續基本原則

• 跟軟體開發流程工具結合– Auto‐Testing

• CI範例介紹– CruiseControl安裝– CruiseControl使用


57

結論

• CI是軟體品質的確認平台– 將其他每個維持品質的工具組織起來，透過不斷

的持續監控整合及品質問題，即時回報狀態給所有成員

– 即使不懂技術的管理者，可以光看報表就知道系統的健康狀況

– 團隊開發時可以及早發現，在整合上是否有所問題

– 團隊每個人可以隨時了解專案目前的狀況，各方面軟體品質的資訊都是透明的

• CI也可以說是一個中大型軟體團隊不得不依賴的機制– 協助明確分工– 協助時程管理

58

Q&A

59

Continuous integration

Documents

Transcript of Continuous integration