基本信息
编辑推荐
重要的邮件太多而无从下手
没有能用于验证的环境
覆盖了其他组员修正的代码
无法自信地进行代码重构
不知道bug的修正日期，也不能追踪退化
……
那么，你可能需要这本书！
系统讲解团队开发所必需的工具和方法
详细介绍各个工具的特性及使用要点，并进行比较
自动化意识贯穿全书，真正实现高效开发
内容摘要：
本书以团队开发中所必需的工具的导入方法和使用方法为核心，对团队开发的整体结构进行概括性的说明。内容涉及团队开发中发生的问题、版本管理系统、缺陷管理系统、持续集成、持续交付以及回归测试，并且对"为什么用那个工具""为什么要这样使用"等开发现场常有的问题进行举例说明。
本书适合初次接手开发团队的项目经理，计划开始新项目的项目经理、Scrum Master，以及现有项目中返工、延期问题频发的开发人员阅读。
内容简介
作译者
池田尚史
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年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。
目录
第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
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
译者序
译者序
《高效团队开发：工具与方法》并不是以实际的项目带你体验多人开发项目的整体流程，而是告诉你使用哪些工具和方法能够实现高效的团队开发。从版本管理系统、缺陷管理系统到CI工具、虚拟化、自动化测试等，无论你使用哪种语言、框架、软件开发模式，无论你是负责开发、测试，还是负责运维、项目管理，都会涉及这些工具。这些工具也直接影响着开发和运维的效率、项目成本以及公司的日常开销。
随着SaaS（软件即服务）的普及，越来越多的项目已经不是经过一段时间的密集开发就结束的了。后期的开发，包括集成、测试、运维（部署、发布等），从重要性以及成本的角度来看都已经成为项目中的重要部分。本书后半部分介绍的持续集成、自动部署（持续交付）以及回归测试，都能有效地帮助这样的项目提高质量、加快开发速度、降低运维成本。
本书让我印象较深的一点是贯穿全书的自动化意识，包括自动化环境构建、持续集成、自动化测试、自动部署和发布。点击鼠标提交代码和测试用例，借助CI和各类自动化工具，自动触发编译、集成、测试、部署，还会自动将版本管理系统中提交的信息关联到缺陷管理和CI系统中，几分钟后打开浏览器就能够"享受"自己的劳动成果了。这样的场景实在太美了。想来是因为日本长期的劳动力不足以及高昂的劳动力成本才让作者对于自动化如此执着。对于还能够享受人口红利的中国软件行业来说，自动化也是非常必要的。除了能够在开发、测试、运维等多方面降低成本之外，自动化环境构建、自动化测试这样的机制能够降低项目对于成员个体的依赖，在大规模的团队开发中以及在灵活调整团队规模方面都是必不可少的。
本书所介绍的内容对于公司来说不仅可以提高效率，降低成本，还可以成为公司的一张名片。持续集成、自动化测试、持续交付，加上Github、Jenkins、Vagrant、Chef、serverspec、Selenium这些工具，由此构筑起的技术堆栈，无论是对于开发、测试人员还是运维人员来说都是非常具有吸引力的。对于个人来说，除了扩展自己的知识之外，还能作为你选择公司的重要参考依据，判断公司是否对技术敏感，推测项目大致的工作流程以及是否可能成为Death march。更重要的是
员工："老板，我要加工资！"
老板："为什么？"
员工："因为我长得帅！"
老板："……"
员工："因为我跟你10年了，没有功劳也有苦劳吧！"
老板："好吧，加5%差不多了。"
员工："这个项目交给我，我有办法只需要一半的人手就能完成！"
老板："真的？好！工资翻倍！"
最后感谢在翻译过程中给予我支持及鼓励的各位。特别是我的妻子，翻译这段时间恰好是她怀孕和生产的时候。我们平安地迎来了家里的新成员滚滚，借此祝愿他健康成长。
严圣逸
2015年3月于上海
《高效团队开发：工具与方法》并不是以实际的项目带你体验多人开发项目的整体流程，而是告诉你使用哪些工具和方法能够实现高效的团队开发。从版本管理系统、缺陷管理系统到CI工具、虚拟化、自动化测试等，无论你使用哪种语言、框架、软件开发模式，无论你是负责开发、测试，还是负责运维、项目管理，都会涉及这些工具。这些工具也直接影响着开发和运维的效率、项目成本以及公司的日常开销。
随着SaaS（软件即服务）的普及，越来越多的项目已经不是经过一段时间的密集开发就结束的了。后期的开发，包括集成、测试、运维（部署、发布等），从重要性以及成本的角度来看都已经成为项目中的重要部分。本书后半部分介绍的持续集成、自动部署（持续交付）以及回归测试，都能有效地帮助这样的项目提高质量、加快开发速度、降低运维成本。
本书让我印象较深的一点是贯穿全书的自动化意识，包括自动化环境构建、持续集成、自动化测试、自动部署和发布。点击鼠标提交代码和测试用例，借助CI和各类自动化工具，自动触发编译、集成、测试、部署，还会自动将版本管理系统中提交的信息关联到缺陷管理和CI系统中，几分钟后打开浏览器就能够"享受"自己的劳动成果了。这样的场景实在太美了。想来是因为日本长期的劳动力不足以及高昂的劳动力成本才让作者对于自动化如此执着。对于还能够享受人口红利的中国软件行业来说，自动化也是非常必要的。除了能够在开发、测试、运维等多方面降低成本之外，自动化环境构建、自动化测试这样的机制能够降低项目对于成员个体的依赖，在大规模的团队开发中以及在灵活调整团队规模方面都是必不可少的。
本书所介绍的内容对于公司来说不仅可以提高效率，降低成本，还可以成为公司的一张名片。持续集成、自动化测试、持续交付，加上Github、Jenkins、Vagrant、Chef、serverspec、Selenium这些工具，由此构筑起的技术堆栈，无论是对于开发、测试人员还是运维人员来说都是非常具有吸引力的。对于个人来说，除了扩展自己的知识之外，还能作为你选择公司的重要参考依据，判断公司是否对技术敏感，推测项目大致的工作流程以及是否可能成为Death march。更重要的是
员工："老板，我要加工资！"
老板："为什么？"
员工："因为我长得帅！"
老板："……"
员工："因为我跟你10年了，没有功劳也有苦劳吧！"
老板："好吧，加5%差不多了。"
员工："这个项目交给我，我有办法只需要一半的人手就能完成！"
老板："真的？好！工资翻倍！"
最后感谢在翻译过程中给予我支持及鼓励的各位。特别是我的妻子，翻译这段时间恰好是她怀孕和生产的时候。我们平安地迎来了家里的新成员滚滚，借此祝愿他健康成长。
严圣逸
2015年3月于上海
序言
序言
本书名为《高效团队开发：工具与方法》。
读者朋友们大多都知道，团队开发是一件复杂、困难的事情。
关于团队开发，现在已经有了各式各样的方法论和工具。方法论方面，除了Scrum、XP等敏捷开发以外，还有些更具体的设计开发方法，如TDD（Test Driven Development，测试驱动开发）、BDD（Behavior Driven Development，行为驱动开发）、TiDD（Ticket Driven Development，缺陷驱动开发）等，以及具体实践，如CI（Continuous Integration，持续集成）、CD（Continuous Delivery，持续交付）等。讲述这些方法论的书籍、杂志以及网站到处都是，甚至多得让人不知该从何处着手。
再看一下从技术上支持这些方法论的工具，缺陷管理系统、版本管理系统、自动化测试、静态分析工具、自动化部署工具等，仅是种类就有很多。即使是简单地列举每一类中具有代表性的工具，其数量就多得令人感到头晕。
并且和数年前相比，支持团队开发的工具已经变得非常易用，能方便地构建高效的开发流程。但由于信息量过多，并且很分散，所以想要系统性地学习或者对新人进行高效的培训都还是比较困难的。正是因为意识到了上述这些问题，笔者才有了写作本书的想法。
本书以团队开发中所必需的工具的导入方法和使用方法为重点，对团队开发的整体结构进行概括性的说明。并且对"为什么用那个工具""为什么要这样使用"等开发现场常有的一些问题进行举例说明。
希望你能喜欢本书。
读者对象
本书适合的读者对象有：初次接手开发团队的项目经理计划开始新项目的项目经理、Scrum Master现有项目中返工、延期问题频发，想了解能帮助自己解决这些问题的工具及其使用方法的人测试是测试部门的事，与己无关；部署、发布是运维部门的事，与己无关--有如此想法的人想了解最近能够在Web服务开发中发挥作用的工具的人
致谢
在写作本书的过程中有幸得到了诸多人士的帮助。在此特别感谢堀让治先生、冈村纯一先生、平田耕造先生、奥村康树先生、吉羽龙太郎先生、藤原大先生、中村知成先生、梅泽雄一郎先生、伊藤望先生、鹿糠秀俊先生、角田良太先生，他们极有耐心地审阅了我们粗劣的原稿，并提出宝贵意见。感谢Vincent Driessen先生和Pablo Santos先生提供的Git-flow图和SCM历史简图以及翻译许可。
还要感谢堀让治先生等想能（SHANON）株式会社的各位，在本书写作期间给予的各类帮助。
还有技术评论社的春原先生，从最初会面到现在的两年时间里，让您费心费力了。您一直极有耐心地等待着我那迟迟没有进展的原稿，实在是非常感谢。
最后要感谢我的妻子和两个孩子，对于休息日一直埋头写作的我，他们没有丝毫埋怨，给予了我百分之百的支持。还有陪着孩子玩耍的岳父岳母，以及我自己的父亲、母亲，谢谢你们！
作者代表池田尚史
2014年3月
本书名为《高效团队开发：工具与方法》。
读者朋友们大多都知道，团队开发是一件复杂、困难的事情。
关于团队开发，现在已经有了各式各样的方法论和工具。方法论方面，除了Scrum、XP等敏捷开发以外，还有些更具体的设计开发方法，如TDD（Test Driven Development，测试驱动开发）、BDD（Behavior Driven Development，行为驱动开发）、TiDD（Ticket Driven Development，缺陷驱动开发）等，以及具体实践，如CI（Continuous Integration，持续集成）、CD（Continuous Delivery，持续交付）等。讲述这些方法论的书籍、杂志以及网站到处都是，甚至多得让人不知该从何处着手。
再看一下从技术上支持这些方法论的工具，缺陷管理系统、版本管理系统、自动化测试、静态分析工具、自动化部署工具等，仅是种类就有很多。即使是简单地列举每一类中具有代表性的工具，其数量就多得令人感到头晕。
并且和数年前相比，支持团队开发的工具已经变得非常易用，能方便地构建高效的开发流程。但由于信息量过多，并且很分散，所以想要系统性地学习或者对新人进行高效的培训都还是比较困难的。正是因为意识到了上述这些问题，笔者才有了写作本书的想法。
本书以团队开发中所必需的工具的导入方法和使用方法为重点，对团队开发的整体结构进行概括性的说明。并且对"为什么用那个工具""为什么要这样使用"等开发现场常有的一些问题进行举例说明。
希望你能喜欢本书。
读者对象
本书适合的读者对象有：初次接手开发团队的项目经理计划开始新项目的项目经理、Scrum Master现有项目中返工、延期问题频发，想了解能帮助自己解决这些问题的工具及其使用方法的人测试是测试部门的事，与己无关；部署、发布是运维部门的事，与己无关--有如此想法的人想了解最近能够在Web服务开发中发挥作用的工具的人
致谢
在写作本书的过程中有幸得到了诸多人士的帮助。在此特别感谢堀让治先生、冈村纯一先生、平田耕造先生、奥村康树先生、吉羽龙太郎先生、藤原大先生、中村知成先生、梅泽雄一郎先生、伊藤望先生、鹿糠秀俊先生、角田良太先生，他们极有耐心地审阅了我们粗劣的原稿，并提出宝贵意见。感谢Vincent Driessen先生和Pablo Santos先生提供的Git-flow图和SCM历史简图以及翻译许可。
还要感谢堀让治先生等想能（SHANON）株式会社的各位，在本书写作期间给予的各类帮助。
还有技术评论社的春原先生，从最初会面到现在的两年时间里，让您费心费力了。您一直极有耐心地等待着我那迟迟没有进展的原稿，实在是非常感谢。
最后要感谢我的妻子和两个孩子，对于休息日一直埋头写作的我，他们没有丝毫埋怨，给予了我百分之百的支持。还有陪着孩子玩耍的岳父岳母，以及我自己的父亲、母亲，谢谢你们！
作者代表池田尚史
2014年3月
媒体评论
《高效团队开发 工具与方法》：
3.7.2 应该如何管理数据库模式
对数据库模式进行版本管理，应该管理什么？又怎么管理呢？让我们具体地来看一下。这里假设数据库为MySQL或PostgreSQL等，也就是说使用了RDBMS，以此为前提来继续下面的话题。但是这里的数据库并不局限于RDBMS，文本文件、XML文件、对象数据库以及最近使用频率逐渐增加的MongoDB等NoSQL数据库，它们的思考方法也是完全相同的。
版本管理的必要条件
对数据库模式进行版本管理的必要条件中，比较重要的是以下3个。
无论什么环境都能用相同的步骤来构建数据库
能够反复执行多次
文本文件
上面这些也是和CI相关联的思考方法。CI相关的内容将在第5章进行说明。对于数据库模式，和代码一样进行版本管理，无论任何环境都能反复构建，这一点是非常重要的。另外，为了用版本管理系统方便地进行合并，以文本文件的形式管理模式也是很重要的。
例如有的开发现场使用商用的GUI工具来建立数据库模式，这样的工具有时反而会影响团队开发的效率。因此一定要以程序能够反复执行的文本文件形式来管理数据库模式。
什么是数据库迁移
数据库模式的CI称为CDBI（Continuous DataBase Integration）。《持续集成：软件质量改进和风险降低之道》中也以专门的章节对其进行了说明。但是最近比起CDBI，使用从RubyonRails的工具名（Migration）衍生而来的“数据迁移”这个叫法的人似乎更多一些。
……
3.7.2 应该如何管理数据库模式
对数据库模式进行版本管理，应该管理什么？又怎么管理呢？让我们具体地来看一下。这里假设数据库为MySQL或PostgreSQL等，也就是说使用了RDBMS，以此为前提来继续下面的话题。但是这里的数据库并不局限于RDBMS，文本文件、XML文件、对象数据库以及最近使用频率逐渐增加的MongoDB等NoSQL数据库，它们的思考方法也是完全相同的。
版本管理的必要条件
对数据库模式进行版本管理的必要条件中，比较重要的是以下3个。
无论什么环境都能用相同的步骤来构建数据库
能够反复执行多次
文本文件
上面这些也是和CI相关联的思考方法。CI相关的内容将在第5章进行说明。对于数据库模式，和代码一样进行版本管理，无论任何环境都能反复构建，这一点是非常重要的。另外，为了用版本管理系统方便地进行合并，以文本文件的形式管理模式也是很重要的。
例如有的开发现场使用商用的GUI工具来建立数据库模式，这样的工具有时反而会影响团队开发的效率。因此一定要以程序能够反复执行的文本文件形式来管理数据库模式。
什么是数据库迁移
数据库模式的CI称为CDBI（Continuous DataBase Integration）。《持续集成：软件质量改进和风险降低之道》中也以专门的章节对其进行了说明。但是最近比起CDBI，使用从RubyonRails的工具名（Migration）衍生而来的“数据迁移”这个叫法的人似乎更多一些。
……
书摘
《高效团队开发 工具与方法》：
3.7.2 应该如何管理数据库模式
对数据库模式进行版本管理，应该管理什么？又怎么管理呢？让我们具体地来看一下。这里假设数据库为MySQL或PostgreSQL等，也就是说使用了RDBMS，以此为前提来继续下面的话题。但是这里的数据库并不局限于RDBMS，文本文件、XML文件、对象数据库以及最近使用频率逐渐增加的MongoDB等NoSQL数据库，它们的思考方法也是完全相同的。
版本管理的必要条件
对数据库模式进行版本管理的必要条件中，比较重要的是以下3个。
无论什么环境都能用相同的步骤来构建数据库
能够反复执行多次
文本文件
上面这些也是和CI相关联的思考方法。CI相关的内容将在第5章进行说明。对于数据库模式，和代码一样进行版本管理，无论任何环境都能反复构建，这一点是非常重要的。另外，为了用版本管理系统方便地进行合并，以文本文件的形式管理模式也是很重要的。
例如有的开发现场使用商用的GUI工具来建立数据库模式，这样的工具有时反而会影响团队开发的效率。因此一定要以程序能够反复执行的文本文件形式来管理数据库模式。
什么是数据库迁移
数据库模式的CI称为CDBI（Continuous DataBase Integration）。《持续集成：软件质量改进和风险降低之道》中也以专门的章节对其进行了说明。但是最近比起CDBI，使用从RubyonRails的工具名（Migration）衍生而来的“数据迁移”这个叫法的人似乎更多一些。
……
3.7.2 应该如何管理数据库模式
对数据库模式进行版本管理，应该管理什么？又怎么管理呢？让我们具体地来看一下。这里假设数据库为MySQL或PostgreSQL等，也就是说使用了RDBMS，以此为前提来继续下面的话题。但是这里的数据库并不局限于RDBMS，文本文件、XML文件、对象数据库以及最近使用频率逐渐增加的MongoDB等NoSQL数据库，它们的思考方法也是完全相同的。
版本管理的必要条件
对数据库模式进行版本管理的必要条件中，比较重要的是以下3个。
无论什么环境都能用相同的步骤来构建数据库
能够反复执行多次
文本文件
上面这些也是和CI相关联的思考方法。CI相关的内容将在第5章进行说明。对于数据库模式，和代码一样进行版本管理，无论任何环境都能反复构建，这一点是非常重要的。另外，为了用版本管理系统方便地进行合并，以文本文件的形式管理模式也是很重要的。
例如有的开发现场使用商用的GUI工具来建立数据库模式，这样的工具有时反而会影响团队开发的效率。因此一定要以程序能够反复执行的文本文件形式来管理数据库模式。
什么是数据库迁移
数据库模式的CI称为CDBI（Continuous DataBase Integration）。《持续集成：软件质量改进和风险降低之道》中也以专门的章节对其进行了说明。但是最近比起CDBI，使用从RubyonRails的工具名（Migration）衍生而来的“数据迁移”这个叫法的人似乎更多一些。
……
