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

目錄
第1章　什么是團隊開發(fā)　　1
1．1　一個人也能進行開發(fā)　2
1．2　團隊開發(fā)面臨的問題　3
1．3　如何解決這些問題　4
1．4　本書的構成　5
1．4．1　第2章：案例分析　5
1．4．2　第3～5章：基礎實踐　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ù)量太多，導致重要的郵件被埋沒　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：法自信地進行代碼重構　24
2．4．4　問題8：不知道bug的修正日期，也不能追蹤退化　25
2．4．5　問題9：沒有靈活使用分支和標簽　26
2．4．6　問題10：在測試環(huán)境、正式環(huán)境上法運行　28
2．4．7　問題11：發(fā)布太復雜，以至于需要發(fā)布手冊　28
2．5　案例分析（第2天）中的問題點　30
2．5．1　問題5：不運行系統(tǒng)就法察覺問題　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：在測試環(huán)境、正式環(huán)境上法運行　35
2．5．7　問題11：發(fā)布太復雜，以至于需要發(fā)布手冊　36
2．6　什么是理想的項目　37
2．6．1　使用缺陷管理系統(tǒng)對課題等進行統(tǒng)籌管理　38
2．6．2　盡量使用版本管理系統(tǒng)　38
2．6．3　準備可以反復驗證的CI系統(tǒng)　38
2．6．4　將環(huán)境的影響控制在最小限度，并隨時可以發(fā)布　39
2．6．5　保留所有記錄以便日后追蹤　39
2．7　本章總結　40
第3章　版本管理　41
3．1　版本管理系統(tǒng)　42
3．1．1　什么是版本管理系統(tǒng)　42
3．1．2　為什么使用版本管理系統(tǒng)能帶來便利　42
能夠保留修改內容這一最基本的記錄　43
能夠方便地查看版本之間的差異　43
能夠防止錯誤地覆蓋他人修改的代碼　43
專欄　鎖模式和合并模式　44
能夠還原到任意時間點的狀態(tài)　48
專欄　基于文件和基于變更集　49
能夠生成多個派生（分支和標簽），保留當時項目狀態(tài)的斷面　49
3．2　版本管理系統(tǒng)的發(fā)展變遷　51
3．2．1　沒有版本管理系統(tǒng)的時代（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　分布式版本管理系統(tǒng)的誕生（2005 年以后）　54
3．2．7　番外篇：GitHub的誕生　55
3．2．8　版本管理系統(tǒng)的導入情況　57
3．3　分布式版本管理系統(tǒng)　59
3．3．1　使用分布式版本管理系統(tǒng)的5 大原因　59
能將代碼庫完整地復制到本地　59
運行速度快　59
臨時作業(yè)的提交易于管理　59
分支、合并簡單方便　59
可以不受地點的限制進行協(xié)作開發(fā)　60
3．3．2　分布式版本管理系統(tǒng)的缺點　60
系統(tǒng)中沒有真正意義上的最新版本　60
沒有真正意義上的版本號　60
工作流程的配置過于靈活，容易產生混亂　61
思維方式的習慣需要一定的時間　61
3．4　如何使用版本管理系統(tǒng)　62
3．4．1　前提　62
3．4．2　版本管理系統(tǒng)管理的對象　62
代碼　63
需求資料、設計資料等文檔　64
數(shù)據(jù)庫模式、數(shù)據(jù)　64
配置文件　64
庫的依賴關系定義　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
分支使用方法總結　72
3．5．2　標簽的使用方法　72
什么是標簽　72
新建標簽　72
標簽的確認　73
標簽的取得　73
專欄　避免使用相同的標簽名和分支名　74
標簽使用方法總結　75
專欄　什么是Detached HEAD　76
3．6　Git的開發(fā)流程　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　數(shù)據(jù)庫模式和數(shù)據(jù)的管理　85
3．7．1　需要對數(shù)據(jù)庫模式進行管理的原因　85
由數(shù)據(jù)庫管理員負責對修改進行管理的情況　85
修改共享數(shù)據(jù)庫的模式的情況　85
3．7．2　應該如何管理數(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　依賴關系的管理　97
3．9．1　依賴關系管理系統(tǒng)　97
JVM　語言　97
腳本語言　98
管理依賴關系的優(yōu)點　98
3．10　本章總結　100
第4章　缺陷管理　101
4．1　缺陷管理系統(tǒng)　102
4．1．1　項目進展不順利的原因　102
4．1．2　用紙、郵件、Excel進行任務管理時的問題　103
4．1．3　導入缺陷管理系統(tǒng)的優(yōu)點　104
具有任務管理所需的基本功能　104
直觀性、檢索性較強　104
能夠對信息進行統(tǒng)一管理及共享　104
能夠生成各類報表　105
能夠和其他系統(tǒng)進行關聯(lián)，具有可擴展性　105
4．1．4　什么是缺陷驅動開發(fā)　106
缺陷驅動開發(fā)的具體步驟　106
專欄　徹底貫徹缺陷驅動開發(fā)的情況　107
4．2　主要的缺陷管理系統(tǒng)　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　選擇工具（缺陷管理系統(tǒng)）的要點　116
專欄　缺陷管理系統(tǒng)的應用事例　117
4．3　缺陷管理系統(tǒng)與版本管理系統(tǒng)的關聯(lián)　118
4．3．1　通過關聯(lián)實現(xiàn)的功能　118
從提交鏈接到問題票　118
從問題票鏈接到提交　118
提交的同時修改問題票的狀態(tài)　119
4．3．2　關聯(lián)的配置方法　119
4．3．3　GitHub　119
GitHub的issue　119
Service　Hooks　120
GitHub和Pivotal　Tracker的關聯(lián)　121
GitHub和JIRA的關聯(lián)　123
4．3．4　Trac/Redmine　124
4．3．5　Backlog　124
Backlog和Git的關聯(lián)　125
Backlog和GitHub的關聯(lián)　126
4．3．6　Git自帶的Hook的使用方法　127
4．4　新功能開發(fā)、修改bug時的工作流程　128
4．4．1　工作流程　128
A建立問題票　128
B指定負責人　129
C開發(fā)　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