持續(xù)集成：軟件質量改進和風險降低之道

定　價：￥59.00

作　者：	（美）Paul M. Duvall （保羅.M. 杜瓦爾）Steve Matyas （史蒂夫.邁耶斯） Andrew Glover（安德魯.格洛弗）著,王海鵬譯
出版社：	電子工業(yè)出版社
叢編項：
標　簽：	軟件工程/開發(fā)項目管理

購買這本書可以去

ISBN：	9787121148699	出版時間：	2012-06-01	包裝：	平裝
開本：	16開	頁數(shù)：	272	字數(shù)：

內容簡介

　　Jolt大獎素有“軟件業(yè)之奧斯卡”的美稱，本叢書精選自Jolt歷屆獲獎圖書，以植根于開發(fā)實踐中的獨到工程思想與杰出方法論為主要甄選方向。本書全面深入地討論持續(xù)集成的各個方面，介紹了一種增加項目可見性、降低項目失敗風險的有效實踐。此外，還介紹了測試驅動、代碼審查、數(shù)據庫集成、信息反饋等實踐和工具。全書列舉了持續(xù)集成系統(tǒng)的優(yōu)缺點，如何去使用持續(xù)集成系統(tǒng)，什么時候使用等，可操作性極強?！冻掷m(xù)集成：軟件質量改進和風險降低之道》榮獲2008年Jolt世界圖書大獎，適合軟件開發(fā)人員及團隊閱讀，還可作為軟件工程方面的教材。

作者簡介

　　Paul M.Duvall是Stelligent公司的CTO。Stelligent公司是一家咨詢公司，他們通過優(yōu)化軟件開發(fā)過程，幫助開發(fā)團隊可靠地、快速地開發(fā)出更好的軟件。他幾乎擔任過軟件開發(fā)項目中的所有職務，從開發(fā)者到測試者再到架構師和項目經理。Paul向各個行業(yè)的客戶提供咨詢，包括金融業(yè)、房地產業(yè)、政府、醫(yī)療衛(wèi)生業(yè)，以及大型的獨立軟件提供商。他是許多知名軟件會議的特邀講演者。他為IBMdeveloperWorks撰寫了一系列的文章，名為“Automation for the People”，他是NFJS 2007Anthology（Pragmatic Programmers，2007）的合著者，也是UML 2Toolkit（Wiley，2003）的貢獻作者。他是臨床研究數(shù)據管理系統(tǒng)和方法的發(fā)明者之一，這個系統(tǒng)和方法正在申請專利。他經常在www.testearly.com和www.integratebutton.com上寫日志。Stephen M. Matyas III是AutomateIT的副總裁。AutomateIT是5AMSolutions公司的一個服務機構，它幫助組織機構通過自動化來改進軟件開發(fā)。Steve在應用軟件工程方面有多重背景，他的客戶包括商業(yè)客戶和政府客戶。Steve擔任過許多種不同的角色，從業(yè)務分析師和項目經理到開發(fā)者、設計者和架構師。他是UML2 Toolkit（Wiley，2003）的貢獻作者。他實踐了許多迭代增量式的方法，包括敏捷方法和Rational UnifiedProcess（RUP）。他的大部分第一手的職業(yè)經驗來自于Java/J2EE定制軟件開發(fā)和服務，在方法學、軟件品質和過程改進方面具有特珠的要求。他擁有弗吉尼亞理工大學的計算機科學學士學位。AndrewGlover是Stelligent公司的總裁。Stelligent公司是一家咨詢公司，他們通過優(yōu)化軟件開發(fā)過程，幫助開發(fā)團隊可靠地、快速地開發(fā)出更好的軟件。Andy經常在北美的各種會議上作為講演嘉賓，他也是NoFluff Just Stuff Software Symposium小組的講演者。他還是Groovy inAction（Manning，2007），Java Testing Patterns（Wiley，2004）及NFJS 2006Anthology（PragmaticProgrammers，2006）的合著者之一。他也是一些在線文章的作者，這些文章發(fā)布在IBM的developerWorks，O’Reilly的ONJava、ONLamp和Dev2Dev門戶站點上。他經常在上寫有關軟件品質的日志。貢獻者簡介LisaPorter是一個顧問團隊的高級技術作者，這個團隊向美國政府提供網絡安全的解決方案。Lisa在本書出版之前提供了技術編輯服務。她早些年曾支持一個包含多個應用程序的大型軟件開發(fā)項目，在需求確定和項目成熟度/能力等活動方面受到了好評。她也進行外語翻譯和架構/工程方面的技術寫作。Lisa從2002年開始就從事編輯書籍和在線出版物的工作。Eric Tavela是5AM Solutions公司的首席架構師。5AMSolutions公司是一個軟件開發(fā)公司，該公司致力于將軟件工程的最佳實踐應用于生命科學的研究工作。Eric的主要工作背景是實現(xiàn)Java/J2EE應用程序及指導面向對象軟件開發(fā)和UML建模。

圖書目錄

出版說明 III
譯者序 VI
Martin Fowler序 IX
Paul Julius序 X
前言 XII
作者簡介 XXII
貢獻者簡介 XXIII
第1部分 CI的背景知識：原則與實踐
第1章啟程 2
1.1 針對每次變更構建軟件 3
開發(fā)人員 4
版本控制庫 6
CI服務器 6
構建腳本 8
反饋機制 9
集成構建計算機 10
1.2 CI的特征 10
源代碼編譯 11
數(shù)據庫集成 12
測試 14
審查 15
部署 17
文檔與反饋 18
1.3 本章小結 18
1.4 問題 19
第2章引入持續(xù)集成 20
2.1 CI生活中的一天 22
2.2 CI的價值是什么 25
減少風險 25
減少重復過程 26
生成可部署的軟件 26
增強項目的可見性 27
建立起更強大的產品信心 27
2.3 什么阻礙了團隊使用CI 27
2.4 如何進行“持續(xù)”集成 28
2.5 項目應該在何時以何種方式實現(xiàn)CI 30
2.6 集成的演進 31
2.7 CI如何與其他開發(fā)實踐配合 32
2.8 CI需要多少時間架設 33
2.9 CI與您 33
2.10 經常提交代碼 34
2.11 不要提交無法構建的代碼 35
2.12 立即修復無法集成的構建 35
2.13 編寫自動化的開發(fā)者測試 35
2.14 必須通過所有測試和審查 36
2.15 執(zhí)行私有構建 36
2.16 避免簽出無法構建的代碼 37
2.17 本章小結 37
2.18 問題 38
第3章利用CI減少風險 39
3.1 風險：沒有可部署的軟件 41
場景：“在我的機器上是行的” 41
解決方案 42
場景：與數(shù)據庫同步 42
解決方案 43
場景：點錯了 43
解決方案 44
3.2 風險：很晚才發(fā)現(xiàn)缺陷 44
場景：回歸測試 44
解決方案 45
場景：測試覆蓋 45
解決方案 46
3.3 風險：缺少項目可見性 46
場景：“您收到了備忘錄嗎？” 47
解決方案 47
場景：不能使軟件可見 47
解決方案 48
3.4 風險：低品質的軟件 48
場景：堅持編碼標準 49
解決方案 49
場景：維持架構 49
解決方案 50
場景：重復的代碼 51
解決方案 51
3.5 本章小結 52
3.6 問題 53
第4章針對每次變更構建軟件 54
4.1 自動化構建 56
4.2 執(zhí)行單命令構建 57
4.3 將構建腳本從IDE中分離 62
4.4 集中放置軟件資產 63
4.5 創(chuàng)建一致的目錄結構 64
4.6 讓構建快速失敗 65
4.7 針對所有環(huán)境構建 65
4.8 構建類型和觸發(fā)機制 67
構建類型 67
私有構建 67
集成構建 67
發(fā)布構建 68
構建觸發(fā)機制 68
觸發(fā)構建 69
4.9 使用專門的集成構建計算機 69
4.10 使用CI服務器 72
4.11 執(zhí)行手工集成構建 72
4.12 執(zhí)行快速構建 73
收集構建測量數(shù)據 74
分析構建測量數(shù)據 75
選擇并實現(xiàn)改進 76
使用專門的集成構建計算機 76
增強集成構建計算機的硬件能力 77
改進測試性能 77
4.13 分階段構建 78
檢查基礎設施 79
優(yōu)化構建過程 79
單獨構建系統(tǒng)組件 80
改進軟件審查的性能 80
執(zhí)行分布式集成構建 81
重新評估 82
4.14 這對您如何生效 82
4.15 本章小結 85
4.16 問題 86
第2部分創(chuàng)建全功能的CI系統(tǒng)
第5章持續(xù)數(shù)據庫集成 90
5.1 自動化數(shù)據庫集成 92
創(chuàng)建數(shù)據庫 94
操作數(shù)據庫 97
創(chuàng)建一段構建數(shù)據庫的結合腳本 98
5.2 使用本地數(shù)據庫沙盒 99
5.3 利用版本控制庫共享數(shù)據庫資產 101
5.4 持續(xù)數(shù)據庫集成 103
5.5 讓開發(fā)者能夠修改數(shù)據庫 104
5.6 開發(fā)團隊共同關注修復失敗構建 104
5.7 讓DBA成為開發(fā)團隊的一員 105
5.8 數(shù)據庫集成和集成按鈕 105
測試 105
審查 105
部署 106
反饋與文檔 106
5.9 本章小結 106
5.10 問題 108
第6章持續(xù)測試 109
6.1 自動化單元測試 111
6.2 自動化組件測試 113
6.3 自動化系統(tǒng)測試 115
6.4 自動化功能測試 117
6.5 對開發(fā)者測試分類 118
6.6 先執(zhí)行較快的測試 120
6.7 為缺陷編寫測試 123
6.8 讓組件測試可重復 128
6.9 將測試用例限制為一個斷言 136
6.10 本章小結 138
6.11 問題 139
第7章持續(xù)審查 140
7.1 審查與測試的區(qū)別 143
7.2 應該以怎樣的頻度執(zhí)行審查 143
7.3 代碼測量指標：歷史 144
7.4 降低代碼復雜度 145
7.5 持續(xù)進行設計復查 147
7.6 通過代碼審查維持組織機構的標準 150
7.7 減少重復的代碼 153
使用PMD-CPD 154
7.8 判斷代碼覆蓋率 157
7.9 持續(xù)評估代碼品質 159
覆蓋率檢查頻度 160
覆蓋率與性能 161
7.10 本章小結 162
7.11 問題 163
第8章持續(xù)部署 164
8.1 隨時隨地發(fā)布可工作的軟件 165
8.2 為庫中的資產打上標簽 166
8.3 得到干凈的環(huán)境 168
8.4 為每一個構建版打上標簽 169
8.5 執(zhí)行所有的測試 170
8.6 創(chuàng)建構建反饋報告 171
8.7 回滾構建的過程能力 172
8.8 本章小結 173
8.9 問題 174
第9章持續(xù)反饋 175
9.1 所有正確的東西 176
正確的信息 177
正確的人 178
正確的時間 179
正確的方式 180
9.2 使用持續(xù)反饋機制 180
電子郵件 180
SMS（文本消息） 182
Ambient Orb和X10設備 184
Windows任務條 188
聲音 188
寬屏顯示器 190
9.3 本章小結 191
9.4 問題 192
后記：CI的未來 193
附錄A CI資源 195
附錄B 評估CI工具 212
參考文獻 238