高效团队开发 工具与方法
目录
第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章 什么是团队开发 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
查看完整
池田尚史（作者）
DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。
Twitter @ikeike443
藤仓和明（作者）
想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。
Twitter @fujya
查看完整
DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。
Twitter @ikeike443
藤仓和明（作者）
想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。
Twitter @fujya
查看完整
《高效团队开发：工具与方法》以团队开发中所必需的工具的导入方法和使用方法为核心，对团队开发的整体结构进行概括性的说明。内容涉及团队开发中发生的问题、版本管理系统、缺陷管理系统、持续集成、持续交付以及回归测试，并且对“为什么用那个工具”“为什么要这样使用”等开发现场常有的问题进行举例说明。
目录
第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
^ 收 起
第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
^ 收 起
池田尚史（作者）
DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。
Twitter @ikeike443
藤仓和明（作者）
想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。
Twitter @fujya
井上史彰（作者）
想能（SHANON）软件工程师、QA工程师，现为想能信息科技（上海）有限公司总经理。开发经验丰富，致力于推动高效的自动化测试。负责本书第7章。
E-mail fu.inoue@gmail.com
严圣逸（译者）
毕业于上海交通大学。8年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。
^ 收 起
DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。
Twitter @ikeike443
藤仓和明（作者）
想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。
Twitter @fujya
井上史彰（作者）
想能（SHANON）软件工程师、QA工程师，现为想能信息科技（上海）有限公司总经理。开发经验丰富，致力于推动高效的自动化测试。负责本书第7章。
E-mail fu.inoue@gmail.com
严圣逸（译者）
毕业于上海交通大学。8年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。
^ 收 起
《高效团队开发：工具与方法》以团队开发中所必需的工具的导入方法和使用方法为核心，对团队开发的整体结构进行概括性的说明。内容涉及团队开发中发生的问题、版本管理系统、缺陷管理系统、持续集成、持续交付以及回归测试，并且对“为什么用那个工具”“为什么要这样使用”等开发现场常有的问题进行举例说明。
比价列表
