高效團隊開發(fā) 工具與方法

目錄
第1章　什么是團隊開發(fā)　　1
1．1　一個人也能進行開發(fā)　2
1．2　團隊開發(fā)面臨的問題　3
1．3　如何解決這些問題　4
1．4　本書的構(gòu)成　5
1．4．1　第2章：案例分析　5
1．4．2　第3～5章：基礎(chǔ)實踐　5
1．4．3　第6～7章：持續(xù)交付和回歸測試　6
1．5　閱讀本書前的注意事項　7
1．5．1　最好的方法是具體問題具體分析　7
1．5．2　沒有最好的工具　7
第2章　團隊開發(fā)中發(fā)生的問題　9
2．1　案例分析的前提　10
2．1．1　項目的前提條件　10
2．2　案例分析（第1天）　11
2．2．1　問題1：重要的郵件太多，法確定處理的優(yōu)先順序　11
2．2．2　問題2：沒有能用于驗證的環(huán)境　11
2．2．3　問題3：用別名目錄管理分支　12
2．2．4　問題4：重新制作數(shù)據(jù)庫比較困難　14
2．3　案例分析（第1天）中的問題點　16
2．3．1　問題1：重要的郵件太多，法確定處理的優(yōu)先順序　16
郵件的數(shù)量太多，導(dǎo)致重要的郵件被埋沒　16
法進行狀態(tài)管理　17
直觀性、檢索性較弱　17
用郵件來管理項目的課題　17
2．3．2　問題2：沒有能用于驗證的環(huán)境　18
2．3．3　問題3：用別名目錄管理分支　18
2．3．4　問題4：重新制作數(shù)據(jù)庫比較困難　19
2．4　案例分析（第2天）　22
2．4．1　問題5：不運行系統(tǒng)就法察覺問題　22
2．4．2　問題6：覆蓋了其他組員修正的代碼　22
2．4．3　問題7：法自信地進行代碼重構(gòu)　24
2．4．4　問題8：不知道bug的修正日期，也不能追蹤退化　25
2．4．5　問題9：沒有靈活使用分支和標(biāo)簽　26
2．4．6　問題10：在測試環(huán)境、正式環(huán)境上法運行　28
2．4．7　問題11：發(fā)布太復(fù)雜，以至于需要發(fā)布手冊　28
2．5　案例分析（第2天）中的問題點　30
2．5．1　問題5：不運行系統(tǒng)就法察覺問題　30
2．5．2　問題6：覆蓋了其他組員修正的代碼　31
2．5．3　問題7：法自信地進行代碼重構(gòu)　31
2．5．4　問題8：不知道bug的修正日期，也不能追蹤退化　33
2．5．5　問題9：沒有靈活使用分支和標(biāo)簽　35
2．5．6　問題10：在測試環(huán)境、正式環(huán)境上法運行　35
2．5．7　問題11：發(fā)布太復(fù)雜，以至于需要發(fā)布手冊　36
2．6　什么是理想的項目　37
2．6．1　使用缺陷管理系統(tǒng)對課題等進行統(tǒng)籌管理　38
2．6．2　盡量使用版本管理系統(tǒng)　38
2．6．3　準(zhǔn)備可以反復(fù)驗證的CI系統(tǒng)　38
2．6．4　將環(huán)境的影響控制在最小限度，并隨時可以發(fā)布　39
2．6．5　保留所有記錄以便日后追蹤　39
2．7　本章總結(jié)　40
第3章　版本管理　41
3．1　版本管理系統(tǒng)　42
3．1．1　什么是版本管理系統(tǒng)　42
3．1．2　為什么使用版本管理系統(tǒng)能帶來便利　42
能夠保留修改內(nèi)容這一最基本的記錄　43
能夠方便地查看版本之間的差異　43
能夠防止錯誤地覆蓋他人修改的代碼　43
專欄　鎖模式和合并模式　44
能夠還原到任意時間點的狀態(tài)　48
專欄　基于文件和基于變更集　49
能夠生成多個派生（分支和標(biāo)簽），保留當(dāng)時項目狀態(tài)的斷面　49
3．2　版本管理系統(tǒng)的發(fā)展變遷　51
3．2．1　沒有版本管理系統(tǒng)的時代（20世紀(jì)70年代以前）　52
3．2．2　RCS 的時代（20世紀(jì)80年代）　52
3．2．3　CVS 的誕生（20世紀(jì)90年代）　52
3．2．4　VSS、Perforce等商用工具的誕生（20 世紀(jì)90 年代）　53
3．2．5　Subversion 的誕生（2000 年以后）　54
3．2．6　分布式版本管理系統(tǒng)的誕生（2005 年以后）　54
3．2．7　番外篇：GitHub的誕生　55
3．2．8　版本管理系統(tǒng)的導(dǎo)入情況　57
3．3　分布式版本管理系統(tǒng)　59
3．3．1　使用分布式版本管理系統(tǒng)的5 大原因　59
能將代碼庫完整地復(fù)制到本地　59
運行速度快　59
臨時作業(yè)的提交易于管理　59
分支、合并簡單方便　59
可以不受地點的限制進行協(xié)作開發(fā)　60
3．3．2　分布式版本管理系統(tǒng)的缺點　60
系統(tǒng)中沒有真正意義上的最新版本　60
沒有真正意義上的版本號　60
工作流程的配置過于靈活，容易產(chǎn)生混亂　61
思維方式的習(xí)慣需要一定的時間　61
3．4　如何使用版本管理系統(tǒng)　62
3．4．1　前提　62
3．4．2　版本管理系統(tǒng)管理的對象　62
代碼　63
需求資料、設(shè)計資料等文檔　64
數(shù)據(jù)庫模式、數(shù)據(jù)　64
配置文件　64
庫的依賴關(guān)系定義　65
3．5　使用Git順利地推進并行開發(fā)　66
3．5．1　分支的用法　66
什么是分支　66
什么是發(fā)布分支（release　branch）　66
克隆和建立分支　67
提交和提交記錄　67
分支的切換　68
修正bug后的提交　69
合并到master　70
向master進行Push　71
分支使用方法總結(jié)　72
3．5．2　標(biāo)簽的使用方法　72
什么是標(biāo)簽　72
新建標(biāo)簽　72
標(biāo)簽的確認(rèn)　73
標(biāo)簽的取得　73
專欄　避免使用相同的標(biāo)簽名和分支名　74
標(biāo)簽使用方法總結(jié)　75
專欄　什么是Detached HEAD　76
3．6　Git的開發(fā)流程　77
3．6．1　Git工作流的模式　77
中央集權(quán)型工作流　77
GitHub型工作流　78
3．6．2　分支策略的模式　79
git-flow　79
github-flow　82
筆者的例子（折衷方案）　83
3．6．3　最合適的流程和分支策略因項目而異　84
3．7　數(shù)據(jù)庫模式和數(shù)據(jù)的管理　85
3．7．1　需要對數(shù)據(jù)庫模式進行管理的原因　85
由數(shù)據(jù)庫管理員負(fù)責(zé)對修改進行管理的情況　85
修改共享數(shù)據(jù)庫的模式的情況　85
3．7．2　應(yīng)該如何管理數(shù)據(jù)庫模式　86
版本管理的必要條件　86
什么是數(shù)據(jù)庫遷移　86
數(shù)據(jù)庫遷移的功能　87
3．7．3　數(shù)據(jù)庫遷移工具　88
Migration（Ruby　on Rails）　88
south（Django）　88
Migrations　Plugin（CakePHP）　89
Evolution（Play　Framework）　89
3．7．4　具體用法（Evolution）　89
規(guī)定　89
SQL文件的執(zhí)行　90
開發(fā)者之間數(shù)據(jù)庫模式的同步　91
一致性問題的管理　93
3．7．5　數(shù)據(jù)庫遷移中的注意點　94
3．8　配置文件的管理　96
3．9　依賴關(guān)系的管理　97
3．9．1　依賴關(guān)系管理系統(tǒng)　97
JVM　語言　97
腳本語言　98
管理依賴關(guān)系的優(yōu)點　98
3．10　本章總結(jié)　100
第4章　缺陷管理　101
4．1　缺陷管理系統(tǒng)　102
4．1．1　項目進展不順利的原因　102
4．1．2　用紙、郵件、Excel進行任務(wù)管理時的問題　103
4．1．3　導(dǎo)入缺陷管理系統(tǒng)的優(yōu)點　104
具有任務(wù)管理所需的基本功能　104
直觀性、檢索性較強　104
能夠?qū)π畔⑦M行統(tǒng)一管理及共享　104
能夠生成各類報表　105
能夠和其他系統(tǒng)進行關(guān)聯(lián)，具有可擴展性　105
4．1．4　什么是缺陷驅(qū)動開發(fā)　106
缺陷驅(qū)動開發(fā)的具體步驟　106
專欄　徹底貫徹缺陷驅(qū)動開發(fā)的情況　107
4．2　主要的缺陷管理系統(tǒng)　108
4．2．1　OSS產(chǎn)品　108
Trac　108
Redmine　109
Bugzilla　110
Mantis　111
4．2．2　商用產(chǎn)品　112
JIRA　112
YouTRACK　113
Pivotal　Tracker　113
Backlog　114
GitHub　115
4．2．3　選擇工具（缺陷管理系統(tǒng)）的要點　116
專欄　缺陷管理系統(tǒng)的應(yīng)用事例　117
4．3　缺陷管理系統(tǒng)與版本管理系統(tǒng)的關(guān)聯(lián)　118
4．3．1　通過關(guān)聯(lián)實現(xiàn)的功能　118
從提交鏈接到問題票　118
從問題票鏈接到提交　118
提交的同時修改問題票的狀態(tài)　119
4．3．2　關(guān)聯(lián)的配置方法　119
4．3．3　GitHub　119
GitHub的issue　119
Service　Hooks　120
GitHub和Pivotal　Tracker的關(guān)聯(lián)　121
GitHub和JIRA的關(guān)聯(lián)　123
4．3．4　Trac/Redmine　124
4．3．5　Backlog　124
Backlog和Git的關(guān)聯(lián)　125
Backlog和GitHub的關(guān)聯(lián)　126
4．3．6　Git自帶的Hook的使用方法　127
4．4　新功能開發(fā)、修改bug時的工作流程　128
4．4．1　工作流程　128
A建立問題票　128
B指定負(fù)責(zé)人　129
C開發(fā)　129
D提交　129
E　Push到代碼庫　129
4．5　回答“那個bug是什么時候修正的”的問題　131
4．5．1　Pivotal Tracker的例子　131
用記憶中殘留的關(guān)鍵字進行檢索　131
檢索　131
通過問題票查找代碼修改　132
4．5．2　Backlog的例子　133
檢索　134
4．6　回答“為什么要這樣修改”的問題　136