作者: [日] 池田尚史/[日] 藤仓和明/[日] 井上史彰 出版社: 人民邮电出版社 副标题: 工具与方法 译者: 严圣逸 出版年: 2015-7 页数: 320 定价: 49.00 装帧: 平装 丛书: 图灵程序设计丛书·程序员修炼系列 ISBN: 9787115295941

内容简介

作者简介： 池田尚史 DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。 Twitter　@ikeike443 藤仓和明 想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。 Twitter　@fujya 井上史彰 想能（SHANON）软件工程师、QA工程师，现为想能信息科技（上海）有限公司总经理。开发经验丰富，致力于推动高效的自动化测试。负责本书第7章。 E-mail　[email protected] 译者简介： 严圣逸 毕业于上海交通大学。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　[email protected] 译者简介： 严圣逸 毕业于上海交通大学。8年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。

网友热评

Henry: 提升开发效率的工具介绍,比较简略.适合了解,拓展阅读.还算不错的一本,值得一读. 五杀摇滚吉他手: Devops基本全覆盖了，包括版本管理（代码＋数据库＋配置＋依赖）、缺陷管理、持续集成（自动化构建与测试）、持续部署（引导+配置＋编排）等。不得不说it工具的发展实在太快了，持续部署现在基本是docker和k8s一统天下。 Brave.Y: 页数不是很多，非常适合CI,CD的启蒙，书中提到了很多相关技术和系统。如果深入这一领域，需要看相关技术的专项书籍。 惟以不永怀: 书中讲的技术已经很老了，docker完全可以替换虚拟机(表述不准确，docker的本质应该是进程而非虚拟机)，服务编排用上k8s也方便很多，开箱即用，理念比书中也先进很多，这本书现在看只能用于回顾历史，技术考古，实用性不是很大了，不过书中所述的一些敏捷理念的实践倒是可以感受下

图书目录

第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 什么是发布分支（releasebranch）　　66 克隆和建立分支　　67 提交和提交记录　　67 分支的切换　　68 修正bug后的提交　　69 合并到master　　70 向master进行Push　　71 分支使用方法总结　　72 3.5.2　标签的使用方法　　72 什么是标签　　72 新建标签　　72 标签的确认　　73 标签的取得　　73 专栏　避免使用相同的标签名和分支名　　74 标签使用方法总结　　75 专栏　什么是DetachedHEAD　　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（RubyonRails）　　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.1　OSS产品　　108 Trac　　108 Redmine　　109 Bugzilla　　110 Mantis　　111 4.2.2　商用产品　　112 JIRA　　112 YouTRACK　　113 PivotalTracker　　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 ServiceHooks　　120 GitHub和PivotalTracker的关联　　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 EPush到代码库　　129 4.5　回答“那个bug是什么时候修正的”的问题　　131 4.5.1　PivotalTracker的例子　　131 用记忆中残留的关键字进行检索　　131 检索　　131 通过问题票查找代码修改　　132 4.5.2　Backlog的例子　　133 检索　　134 4.6　回答“为什么要这样修改”的问题　　136 4.7　本章总结　　137 专栏　缺陷管理、bug管理以及需求管理　　137 第5章　CI（持续集成）　　141 5.1　CI（持续集成）　　142 5.1.1　什么是CI（持续集成）　　142 集成（integration）　　142 持续地进行集成就是CI　　142 5.1.2　使开发敏捷化　　143 瀑布式开发的开发阶段　　143 敏捷开发的开发阶段　　144 5.1.3　为什么要进行CI这样的实践　　147 成本效益　　147 市场变化的速度　　148 兼顾开发速度和质量　　148 5.1.4　CI的必要条件　　149 版本管理系统　　149 build工具　　149 测试代码　　151 CI工具　　151 5.1.5　编写测试代码所需的框架　　151 测试驱动开发（TDD）的框架　　151 行为驱动开发（BDD）的框架　　152 5.1.6　主要的CI工具　　154 Jenkins　　154 TravisCI　　155 5.2　build工具的使用方法　　157 5.2.1　新建工程的情况　　157 建立工程雏形　　158 依赖关系的定义　　160 执行测试　　161 导入Eclipse　　162 5.2.2　为已有工程添加自动build功能　　162 5.2.3　build工具的总结　　163 5.3　测试代码的写法　　164 5.3.1　作为CI的对象的测试的种类　　164 5.3.2　何时编写测试　　165 新建工程的情况　　165 已有工程中没有测试的情况　　165 修改bug或添加新功能的情况　　166 5.3.3　棘手的测试该如何写　　166 和外部系统有交互的测试　　166 使用mocking框架进行测试　　167 使用内存数据库进行测试　　168 数据库变更管理和配置文件管理的测试　　169 UI相关的测试　　169 棘手的测试要权衡工数　　170 5.4　执行基于Jenkins的CI　　171 5.4.1　Jenkins的安装　　171 使用本地安装包进行安装　　172 5.4.2　Jenkins能干些什么　　172 5.4.3　新建任务　　173 5.4.4　下载代码　　173 5.4.5　自动执行build和测试　　175 定期执行　　175 轮询版本管理系统　　175 专栏　从版本管理系统进行Push　　176 build的记述　　177 5.4.6　统计结果并生成报表　　178 专栏　以JUnitXML的形式输出报表比较高效　　179 5.4.7　统计覆盖率　　179 覆盖率统计工具　　180 MavenCobertura插件的安装　　180 专栏　Java程序库的查找方法　　182 Jenkins插件的配置　　183 5.4.8　静态分析　　184 5.4.9　配置通知　　185 5.5　CI的运用　　187 5.5.1　build失败了该怎么办　　187 Subversion等中央集权型版本管理系统的情况　　187 Git等分布式管理系统的情况　　187 专栏　造成build失败后的惩罚游戏　　188 测试后合并　　189 5.5.2　确保可追溯性　　193 关联build和提交　　193 关联缺陷管理　　194 5.6　本章总结——借助CI能够实现的事　　198 第6章　部署的自动化（持续交付）　　199 6.1　应该如何部署　　200 6.1.1　部署自动化带来的好处　　200 细粒度、频繁地发布可以使风险可控　　200 能尽快地获得用户的反馈　　200 团队的规模可控　　201 6.2　部署的自动化　　202 6.2.1　部署自动化方面的共识　　202 6.2.2　部署流水线　　203 通过自动化加快部署速度　　204 任何人都能够实施部署是很重要的　　204 6.2.3　服务提供工具链（provisioningtoolchain）　　204 6.3　引导（Bootstrapping）　　206 6.3.1　Kickstart　　206 Kickstart的使用方法　　206 使用时的注意事项　　206 Kickstart的配置示例　　207 6.3.2　Vagrant　　208 为每一位开发人员准备实体电脑比较困难　　208 使用虚拟机时的注意事项　　209 什么是Vagrant　　209 Vagrant的安装及运行方法　　209 6.4　配置（Configuration）　　212 6.4.1　不使用自动化时的问题　　212 6.4.2　Chef　　213 Chef的构成　　213 目录构成和文件配置　　215 node.json　　215 setup.json　　216 solo.rb　　216 default.rb　　217 virtualhost.conf.erb　　218 Chef的运行方法和运行结果　　218 使用Chef的优点　　219 使用Chef时的注意事项　　220 使用Chef的时间点　　220 6.4.3　serverspec　　221 什么是serverspec　　221 serverspec的安装　　221 测试文件的记述方式　　222 httpd_spec.rb　　222 git_spec.rb　　223 serverspec的执行方法及执行结果　　223 serverspec的优点　　224 6.4.4　最佳实践（其1）　　224 Vagrantfile　　226 default.rb　　227 6.4.5　最佳实践（其2）　　227 6.4.6　实现物理服务器投入运营为止的所有步骤的自动化　　229 6.5　编配（Orchestration）　　230 6.5.1　发布作业的反面教材　　230 6.5.2　Capistrano　　231 Capistrano的系统构成　　231 Capistrano的安装　　232 deploy.rb　　232 Capistrano的执行方法　　233 6.5.3　Fabric　　233 Fabric（串行执行）的情况　　234 Capistrano（并行执行）的情况　　234 理解本地服务器和远程服务器操作上的区别　　234 Fabric的运行方法　　236 6.5.4　Jenkins　　237 主节点（masternode）和从节点（slavenode）的协作　　237 从节点的添加　　238 任务的添加　　240 任务的执行　　242 6.5.5　最佳实践　　243 结合Jenkins和Fabric　　243 6.5.6　考虑安全问题　　244 专栏　手动部署的例子　　245 6.6　考虑运用相关的问题　　247 6.6.1　不中断服务的部署方法　　247 6.6.2　蓝绿部署（blue-greendeployment）　　247 6.6.3　云（cloud）时代的蓝绿部署　　250 6.6.4　回滚（rollback）相关问题的考察　　251 随时准备好退路　　251 数据库模式的版本管理　　251 回滚的验证　　252 只更新代码的发布时的回滚　　252 数据库模式更新时的回滚　　253 6.7　本章总结　　255 专栏　PaaS的使用方式　　255 第7章　回归测试　　259 7.1　回归测试　　260 7.1.1　什么是回归测试　　260 7.1.2　测试分类的整理　　261 支持团队的技术层面的测试（第1象限）　　262 支持团队的业务层面的测试（第2象限）　　262 评价产品的业务层面的测试（第3象限）　　262 使用技术层面测试的产品评价（第4象限）　　263 7.1.3　回归测试的必要性　　263 退化（degrade）的发生　　263 应该实现自动测试的原因　　263 7.1.4　回归测试自动化的目标　　265 7.2　Selenium　　266 7.2.1　什么是Selenium　　266 7.2.2　Selenium的优点　　266 自动化测试用例制作简单　　266 支持多种浏览器及OS　　266 7.2.3　Selenium的组件　　267 SeleniumIDE　　267 SeleniumRemoteControl（SeleniumRC）　　268 SeleniumWebDriver　　269 7.2.4　测试用例的制作和执行　　271 SelemiumIDE的安装和运行　　271 Selenium的测试用例　　271 什么是好的测试用例　　274 用SeleniumServer来运行测试　　274 7.2.5　Selenium的实际应用　　276 测试页面是否有改动　　276 使Selenium测试稳定运行　　278 7.3　Jenkins和Selenium的协作　　282 7.3.1　关联Jenkins和Selenium的步骤　　282 7.4　Selenium测试的高速化　　287 7.4.1　利用Jenkins的分布式构建实现测试的并行执行　　288 Jenkins的分布式构建的构成　　288 分布式构建的配置　　289 7.4.2　Selenium测试并行化中的难点　　291 7.5　多个应用程序版本的测试　　295 7.5.1　应用的部署　　296 7.5.2　从版本管理系统下载测试用例　　296 7.5.3　用Selenium测试　　296