高效团队开发 工具与方法

《高效团队开发：工具与方法》以团队开发中所必需的工具的导入方法和使用方法为核心，对团队开发的整体结构进行概括性的说明。内容涉及团队开发中发生的问题、版本管理系统、缺陷管理系统、持续集成、持续交付以及回归测试，并且对“为什么用那个工具”“为什么要这样使用”等开发现场常有的问题进行举例说明。

池田尚史（作者）
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年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。

目录

第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．2RCS 的时代（20世纪80年代）52
3．2．3CVS 的诞生（20世纪90年代）52
3．2．4VSS、Perforce等商用工具的诞生（20 世纪90 年代）53
3．2．5Subversion 的诞生（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
什么是发布分支（releasebranch）66
克隆和建立分支67
提交和提交记录67
分支的切换68
修正bug后的提交69
合并到master70
向master进行Push71
分支使用方法总结72
3．5．2标签的使用方法72
什么是标签72
新建标签72
标签的确认73
标签的取得73
专栏避免使用相同的标签名和分支名74
标签使用方法总结75
专栏什么是Detached HEAD76
3．6Git的开发流程77
3．6．1Git工作流的模式77
中央集权型工作流77
GitHub型工作流78
3．6．2分支策略的模式79
git-flow79
github-flow82
笔者的例子（折衷方案）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（Rubyon Rails）88
south（Django）88
MigrationsPlugin（CakePHP）89
Evolution（PlayFramework）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．1OSS产品108
Trac108
Redmine109
Bugzilla110
Mantis111
4．2．2商用产品112
JIRA112
YouTRACK113
PivotalTracker113
Backlog114
GitHub115
4．2．3选择工具（缺陷管理系统）的要点116
专栏缺陷管理系统的应用事例117
4．3缺陷管理系统与版本管理系统的关联118
4．3．1通过关联实现的功能118
从提交链接到问题票118
从问题票链接到提交118
提交的同时修改问题票的状态119
4．3．2关联的配置方法119
4．3．3GitHub119
GitHub的issue119
ServiceHooks120
GitHub和PivotalTracker的关联121
GitHub和JIRA的关联123
4．3．4Trac/Redmine124
4．3．5Backlog124
Backlog和Git的关联125
Backlog和GitHub的关联126
4．3．6Git自带的Hook的使用方法127
4．4新功能开发、修改bug时的工作流程128
4．4．1工作流程128
A建立问题票128
B指定负责人129
C开发129
D提交129
EPush到代码库129
4．5回答“那个bug是什么时候修正的”的问题131
4．5．1Pivotal Tracker的例子131
用记忆中残留的关键字进行检索131
检索131
通过问题票查找代码修改132
4．5．2Backlog的例子133
检索134
4．6回答“为什么要这样修改”的问题136

《高效团队开发 工具与方法》：
3.7.2 应该如何管理数据库模式
对数据库模式进行版本管理，应该管理什么？又怎么管理呢？让我们具体地来看一下。这里假设数据库为MySQL或PostgreSQL等，也就是说使用了RDBMS，以此为前提来继续下面的话题。但是这里的数据库并不局限于RDBMS，文本文件、XML文件、对象数据库以及最近使用频率逐渐增加的MongoDB等NoSQL数据库，它们的思考方法也是完全相同的。
版本管理的必要条件
对数据库模式进行版本管理的必要条件中，比较重要的是以下3个。
无论什么环境都能用相同的步骤来构建数据库
能够反复执行多次
文本文件
上面这些也是和CI相关联的思考方法。CI相关的内容将在第5章进行说明。对于数据库模式，和代码一样进行版本管理，无论任何环境都能反复构建，这一点是非常重要的。另外，为了用版本管理系统方便地进行合并，以文本文件的形式管理模式也是很重要的。
例如有的开发现场使用商用的GUI工具来建立数据库模式，这样的工具有时反而会影响团队开发的效率。因此一定要以程序能够反复执行的文本文件形式来管理数据库模式。
什么是数据库迁移
数据库模式的CI称为CDBI（Continuous DataBase Integration）。《持续集成：软件质量改进和风险降低之道》中也以专门的章节对其进行了说明。但是最近比起CDBI，使用从RubyonRails的工具名（Migration）衍生而来的“数据迁移”这个叫法的人似乎更多一些。
……