第1章　什麼是團隊開發　　1
1.1　一個人也能進行開發　　2
1.2　團隊開發麵臨的問題　　3
1.3　如何解決這些問題　　4
1.4　本書的構成　　5
1.4.1　第2章：案例分析　　5
1.4.2　第3～5章：基礎實踐　　5
1.4.3　第6～7章：持續交付和迴歸測試　　6
1.5　閱讀本書前的注意事項　　7
1.5.1　最好的方法是具體問題具體分析　　7
1.5.2　沒有最好的工具　　7
第2章　團隊開發中發生的問題　　9
2.1　案例分析的前提　　10
2.1.1　項目的前提條件　　10
2.2　案例分析（第1天）　　11
2.2.1　問題1：重要的郵件太多，無法確定處理的優先順序　　11
2.2.2　問題2：沒有能用於驗證的環境　　11
2.2.3　問題3：用彆名目錄管理分支　　12
2.2.4　問題4：重新製作數據庫比較睏難　　14
2.3　案例分析（第1天）中的問題點　　16
2.3.1　問題1：重要的郵件太多，無法確定處理的優先順序　　16
郵件的數量太多，導緻重要的郵件被埋沒　　16
無法進行狀態管理　　17
直觀性、檢索性較弱　　17
用郵件來管理項目的課題　　17
2.3.2　問題2：沒有能用於驗證的環境　　18
2.3.3　問題3：用彆名目錄管理分支　　18
2.3.4　問題4：重新製作數據庫比較睏難　　19
2.4　案例分析（第2天）　　22
2.4.1　問題5：不運行係統就無法察覺問題　　22
2.4.2　問題6：覆蓋瞭其他組員修正的代碼　　22
2.4.3　問題7：無法自信地進行代碼重構　　24
2.4.4　問題8：不知道bug的修正日期，也不能追蹤退化　　25
2.4.5　問題9：沒有靈活使用分支和標簽　　26
2.4.6　問題10：在測試環境、正式環境上無法運行　　28
2.4.7　問題11：發布太復雜，以至於需要發布手冊　　28
2.5　案例分析（第2天）中的問題點　　30
2.5.1　問題5：不運行係統就無法察覺問題　　30
2.5.2　問題6：覆蓋瞭其他組員修正的代碼　　31
2.5.3　問題7：無法自信地進行代碼重構　　31
2.5.4　問題8：不知道bug的修正日期，也不能追蹤退化　　33
2.5.5　問題9：沒有靈活使用分支和標簽　　35
2.5.6　問題10：在測試環境、正式環境上無法運行　　35
2.5.7　問題11：發布太復雜，以至於需要發布手冊　　36
2.6　什麼是理想的項目　　37
2.6.1　使用缺陷管理係統對課題等進行統籌管理　　38
2.6.2　盡量使用版本管理係統　　38
2.6.3　準備可以反復驗證的CI係統　　38
2.6.4　將環境的影響控製在最小限度，並隨時可以發布　　39
2.6.5　保留所有記錄以便日後追蹤　　39
2.7　本章總結　　40
第3章　版本管理　　41
3.1　版本管理係統　　42
3.1.1　什麼是版本管理係統　　42
3.1.2　為什麼使用版本管理係統能帶來便利　　42
能夠保留修改內容這一最基本的記錄　　43
能夠方便地查看版本之間的差異　　43
能夠防止錯誤地覆蓋他人修改的代碼　　43
專欄　鎖模式和閤並模式 　　44
能夠還原到任意時間點的狀態　　48
專欄　基於文件和基於變更集 　　49
能夠生成多個派生（分支和標簽），保留當時項目狀態的斷麵　　 49
3.2　版本管理係統的發展變遷　　51
3.2.1　沒有版本管理係統的時代（20世紀70年代以前）　　52
3.2.2　RCS 的時代（20世紀80年代）　　52
3.2.3　CVS 的誕生（20世紀90年代）　　52
3.2.4　VSS、Perforce等商用工具的誕生（20 世紀90 年代）　　53
3.2.5　Subversion 的誕生（2000 年以後）　　54
3.2.6　分布式版本管理係統的誕生（2005 年以後）　　54
3.2.7　番外篇：GitHub的誕生　　55
3.2.8　版本管理係統的導入情況　　57
3.3　分布式版本管理係統　　59
3.3.1　使用分布式版本管理係統的5 大原因　　59
能將代碼庫完整地復製到本地　　59
運行速度快　　59
臨時作業的提交易於管理　　59
分支、閤並簡單方便　　59
可以不受地點的限製進行協作開發　　60
3.3.2　分布式版本管理係統的缺點　　60
係統中沒有真正意義上的最新版本　　60
沒有真正意義上的版本號　　60
工作流程的配置過於靈活，容易産生混亂　　61
思維方式的習慣需要一定的時間　　61
3.4　如何使用版本管理係統　　62
3.4.1　前提　　62
3.4.2　版本管理係統管理的對象　　62
代碼　　63
需求資料、設計資料等文檔　　64
數據庫模式、數據　　64
配置文件　　64
庫的依賴關係定義　　65
3.5　使用Git順利地推進並行開發　　66
3.5.1　分支的用法　　66
什麼是分支　　66
什麼是發布分支（release branch）　　66
剋隆和建立分支　　67
提交和提交記錄　　67
分支的切換　　68
修正bug後的提交　　69
閤並到master　　70
嚮master進行Push　　71
分支使用方法總結　　72
3.5.2　標簽的使用方法　　72
什麼是標簽　　72
新建標簽　　72
標簽的確認　　73
標簽的取得　　73
專欄　避免使用相同的標簽名和分支名 　　74
標簽使用方法總結　　75
專欄　什麼是Detached HEAD 　　76
3.6　Git的開發流程　　77
3.6.1　Git工作流的模式　　77
中央集權型工作流　　77
GitHub型工作流　　78
3.6.2　分支策略的模式　　79
git-flow　　79
github-flow　　82
筆者的例子（摺衷方案）　　83
3.6.3　最閤適的流程和分支策略因項目而異　　84
3.7　數據庫模式和數據的管理　　85
3.7.1　需要對數據庫模式進行管理的原因　　85
由數據庫管理員負責對修改進行管理的情況 　　85
修改共享數據庫的模式的情況 　　85
3.7.2　應該如何管理數據庫模式　　86
版本管理的必要條件　　86
什麼是數據庫遷移　　86
數據庫遷移的功能　　87
3.7.3　數據庫遷移工具　　88
Migration（Ruby on Rails） 　　88
south（Django）　　88
Migrations Plugin（CakePHP）　　89
Evolution（Play Framework）　　89
3.7.4　具體用法（Evolution）　　89
規定　　89
SQL文件的執行　　90
開發者之間數據庫模式的同步 　　91
一緻性問題的管理　　93
3.7.5　數據庫遷移中的注意點　　94
3.8　配置文件的管理　　96
3.9　依賴關係的管理　　97
3.9.1　依賴關係管理係統　　97
JVM 語言　　97
腳本語言　　98
管理依賴關係的優點　　98
3.10　本章總結　　100
第4章　缺陷管理　　101
4.1　缺陷管理係統　　102
4.1.1　項目進展不順利的原因　　102
4.1.2　用紙、郵件、Excel進行任務管理時的問題　　103
4.1.3　導入缺陷管理係統的優點　　104
具有任務管理所需的基本功能　　104
直觀性、檢索性較強　　104
能夠對信息進行統一管理及共享　　104
能夠生成各類報錶　　105
能夠和其他係統進行關聯，具有可擴展性　　105
4.1.4　什麼是缺陷驅動開發　　106
缺陷驅動開發的具體步驟　　106
專欄　徹底貫徹缺陷驅動開發的情況 　　107
4.2　主要的缺陷管理係統　　108
4.2.1　OSS産品　　108
Trac　　108
Redmine　　109
Bugzilla　　110
Mantis　　111
4.2.2　商用産品　　112
JIRA　　112
YouTRACK　　113
Pivotal Tracker　　113
Backlog　　114
GitHub　　115
4.2.3　選擇工具（缺陷管理係統）的要點　　116
專欄　缺陷管理係統的應用事例 　　117
4.3　缺陷管理係統與版本管理係統的關聯　　118
4.3.1　通過關聯實現的功能　　118
從提交鏈接到問題票　　118
從問題票鏈接到提交　　118
提交的同時修改問題票的狀態　　119
4.3.2　關聯的配置方法　　119
4.3.3　GitHub　　119
GitHub的issue　　119
Service Hooks　　120
GitHub和Pivotal Tracker的關聯　　121
GitHub和JIRA的關聯　　123
4.3.4　Trac/Redmine　　124
4.3.5　Backlog　　124
Backlog和Git的關聯　　125
Backlog和GitHub的關聯　　126
4.3.6　Git自帶的Hook的使用方法　　127
4.4　新功能開發、修改bug時的工作流程　　128
4.4.1　工作流程　　128
A建立問題票　　128
B指定負責人　　129
C開發　　129
D提交　　129
E Push到代碼庫　　129
4.5　迴答“那個bug是什麼時候修正的”的問題　　 131
4.5.1　Pivotal Tracker的例子　　131
用記憶中殘留的關鍵字進行檢索　　131
檢索　　131
通過問題票查找代碼修改　　132
4.5.2　Backlog的例子　　133
檢索　　134
4.6　迴答“為什麼要這樣修改”的問題　　136
4.7　本章總結　　137
專欄　缺陷管理、bug 管理以及需求管理 　　137
第5章　CI（持續集成）　　141
5.1　CI（持續集成）　　142
5.1.1　什麼是CI（持續集成）　　142
集成（integration）　　142
持續地進行集成就是CI　　142
5.1.2　使開發敏捷化　　143
瀑布式開發的開發階段　　143
敏捷開發的開發階段　　144
5.1.3　為什麼要進行CI 這樣的實踐　　147
成本效益　　147
市場變化的速度　　148
兼顧開發速度和質量　　148
5.1.4　CI的必要條件　　149
版本管理係統　　149
build 工具　　149
測試代碼　　151
CI 工具　　151
5.1.5　編寫測試代碼所需的框架　　151
測試驅動開發（TDD）的框架　　151
行為驅動開發（BDD）的框架　　152
5.1.6　主要的CI 工具　　154
Jenkins　　154
TravisCI　　155
5.2　build工具的使用方法　　157
5.2.1　新建工程的情況　　157
建立工程雛形　　158
依賴關係的定義　　160
執行測試　　161
導入Eclipse　　162
5.2.2　為已有工程添加自動build 功能　　162
5.2.3　build工具的總結　　163
5.3　測試代碼的寫法　　164
5.3.1　作為CI的對象的測試的種類　　164
5.3.2　何時編寫測試　　165
新建工程的情況　　165
已有工程中沒有測試的情況　　165
修改bug或添加新功能的情況　　166
5.3.3　棘手的測試該如何寫　　166
和外部係統有交互的測試　　166
使用mocking框架進行測試　　167
使用內存數據庫進行測試　　168
數據庫變更管理和配置文件管理的測試　　169
UI 相關的測試　　169
棘手的測試要權衡工數　　170
5.4　執行基於Jenkins 的CI　　171
5.4.1　Jenkins的安裝　　171
使用本地安裝包進行安裝　　172
5.4.2　Jenkins能乾些什麼　　172
5.4.3　新建任務　　173
5.4.4　下載代碼　　173
5.4.5　自動執行build 和測試　　175
定期執行　　175
輪詢版本管理係統　　175
專欄　 從版本管理係統進行Push 　　176
build 的記述　　177
5.4.6　統計結果並生成報錶　　178
專欄　以JUnitXML 的形式輸齣報錶比較高效 　　179
5.4.7　統計覆蓋率　　179
覆蓋率統計工具　　180
Maven Cobertura插件的安裝　　180
專欄　Java 程序庫的查找方法 　　182
Jenkins 插件的配置　　183
5.4.8　靜態分析　　184
5.4.9　配置通知　　185
5.5　CI 的運用　　187
5.5.1　build 失敗瞭該怎麼辦　　187
Subversion 等中央集權型版本管理係統的情況　　187
Git 等分布式管理係統的情況　　187
專欄　造成build 失敗後的懲罰遊戲 　　188
測試後閤並　　189
5.5.2　確保可追溯性　　193
關聯build 和提交　　193
關聯缺陷管理　　194
5.6　本章總結——藉助CI 能夠實現的事　　198
第6章　部署的自動化（持續交付）　　199
6.1　應該如何部署　　200
6.1.1　部署自動化帶來的好處　　200
細粒度、頻繁地發布可以使風險可控　　200
能盡快地獲得用戶的反饋　　200
團隊的規模可控　　201
6.2　部署的自動化　　202
6.2.1　部署自動化方麵的共識　　202
6.2.2　部署流水綫　　203
通過自動化加快部署速度　　204
任何人都能夠實施部署是很重要的　　204
6.2.3　服務提供工具鏈（provisioning tool chain）　　204
6.3　引導（Bootstrapping）　　206
6.3.1　Kickstart　　206
Kickstart 的使用方法　　206
使用時的注意事項　　206
Kickstart 的配置示例　　207
6.3.2　Vagrant　　208
為每一位開發人員準備實體電腦比較睏難　　208
使用虛擬機時的注意事項　　209
什麼是Vagrant　　209
Vagrant的安裝及運行方法　　209
6.4　配置（Configuration）　　212
6.4.1　不使用自動化時的問題　　212
6.4.2　Chef　　213
Chef的構成　　213
目錄構成和文件配置　　215
node.json　　215
setup.json　　216
solo.rb　　216
default.rb　　217
virtualhost.conf.erb　　218
Chef的運行方法和運行結果　　218
使用Chef的優點　　219
使用Chef時的注意事項　　220
使用Chef的時間點　　220
6.4.3　serverspec　　221
什麼是serverspec　　221
serverspec的安裝　　221
測試文件的記述方式　　222
httpd_spec.rb　　222
git_spec.rb　　223
serverspec的執行方法及執行結果　　223
serverspec的優點　　224
6.4.4　最佳實踐（其1）　　224
Vagrantfile　　226
default.rb　　227
6.4.5　最佳實踐（其2）　　227
6.4.6　實現物理服務器投入運營為止的所有步驟的自動化　　229
6.5　編配（Orchestration）　　230
6.5.1　發布作業的反麵教材　　230
6.5.2　Capistrano　　231
Capistrano的係統構成　　231
Capistrano的安裝　　232
deploy.rb　　232
Capistrano 的執行方法　　233
6.5.3　Fabric　　233
Fabric（串行執行）的情況　　234
Capistrano（並行執行）的情況　　234
理解本地服務器和遠程服務器操作上的區彆　　234
Fabric的運行方法　　236
6.5.4　Jenkins　　237
主節點（master node）和從節點（slave node）的協作　　237
從節點的添加　　238
任務的添加　　240
任務的執行　　242
6.5.5　最佳實踐　　243
結閤Jenkins和Fabric　　243
6.5.6　考慮安全問題　　244
專欄　手動部署的例子 　　245
6.6　考慮運用相關的問題　　247
6.6.1　不中斷服務的部署方法　　247
6.6.2　藍綠部署（blue-green deployment）　　247
6.6.3　雲（cloud）時代的藍綠部署　　250
6.6.4　迴滾（rollback）相關問題的考察　　251
隨時準備好退路　　251
數據庫模式的版本管理　　251
迴滾的驗證　　252
隻更新代碼的發布時的迴滾　　252
數據庫模式更新時的迴滾　　253
6.7　本章總結　　255
專欄　PaaS的使用方式 　　255
第7章　迴歸測試　　259
7.1　迴歸測試　　260
7.1.1　什麼是迴歸測試　　260
7.1.2　測試分類的整理　　261
支持團隊的技術層麵的測試（第1 象限）　　262
支持團隊的業務層麵的測試（第2 象限）　　262
評價産品的業務層麵的測試（第3象限）　　262
使用技術層麵測試的産品評價（第4象限）　　263
7.1.3　迴歸測試的必要性　　263
退化（degrade）的發生　　263
應該實現自動測試的原因　　263
7.1.4　迴歸測試自動化的目標　　265
7.2　Selenium　　266
7.2.1　什麼是Selenium　　266
7.2.2　Selenium的優點　　266
自動化測試用例製作簡單　　266
支持多種瀏覽器及OS　　266
7.2.3　Selenium的組件　　267
Selenium IDE　　267
Selenium Remote Control（Selenium RC）　　268
Selenium WebDriver　　269
7.2.4　測試用例的製作和執行　　271
Selemium IDE的安裝和運行　　271
Selenium的測試用例　　271
什麼是好的測試用例　　274
用Selenium Server來運行測試　　274
7.2.5　Selenium的實際應用　　276
測試頁麵是否有改動　　276
使Selenium測試穩定運行　　278
7.3　Jenkins和Selenium的協作　　282
7.3.1　關聯Jenkins和Selenium的步驟　　282
7.4　Selenium測試的高速化　　287
7.4.1　利用Jenkins的分布式構建實現測試的並行執行　　288
Jenkins的分布式構建的構成　　288
分布式構建的配置　　289
7.4.2　Selenium測試並行化中的難點　　291
7.5　多個應用程序版本的測試　　295
7.5.1　應用的部署　　296
7.5.2　從版本管理係統下載測試用例　　296
7.5.3　用Selenium測試　　296
· · · · · · (收起)