[图灵程序设计丛书].高效团队开发:工具与方法 🔍
[日] 池田尚史 / [日] 藤仓和明 / [日] 井上史彰
北京:人民邮电出版社, Tu ling cheng xu she ji cong shu, Di 1 ban, Beijing, 2015
英语 [en] · 中文 [zh] · PDF · 21.5MB · 2015 · 📘 非小说类图书 · 🚀/duxiu/lgli/upload/zlib · Save
描述
Advances in Imaging and Electron Physics merges two long-running serials-Advances in Electronics and Electron Physics and Advances in Optical and Electron Microscopy. This series features extended articles on the physics of electron devices (especially semiconductor devices), particle optics at high and low energies, microlithography, image science and digital image processing, electromagnetic wave propagation, electron microscopy, and the computing methods used in all these domains. - Discusses Spectral Color Spaces - Covers Phase Contrast Enhancement with Phase Plates in Electron Microscopy - Studies the Optical Properties of Gas Phase Field Ionization Sources - Looks at Symmetric and Nonsymmetric Divergence Measures and Their Generalizations - Describes the features and future of the International System of Units (SI) - Illustrates Importance Sampling Hough Transform
备用文件名
lgli/[日] 池田尚史 / [日] 藤仓和明 / [日] 井上史彰 - [图灵程序设计丛书].高效团队开发:工具与方法.pdf
备用文件名
zlib/no-category/[日] 池田尚史 / [日] 藤仓和明 / [日] 井上史彰/[图灵程序设计丛书].高效团队开发:工具与方法_22278339.pdf
备选标题
Advances in Imaging and Electron Physics, Volume 138 (Advances in Imaging and Electron Physics)
备选标题
Efficient team development tools and methods(Chinese Edition)
备选作者
Adobe InDesign CS6 (Windows)
备选作者
[ RI ] CHI TIAN SHANG SHI
备选作者
(日)池田尚史,(日)藤仓和明,(日)井上史彰著
备选作者
Peter W. Hawkes
备用出版商
The People's Posts and Telecommunications Publishing House
备用出版商
Academic Press, Incorporated
备用出版商
Morgan Kaufmann Publishers
备用出版商
Elsevier/ Academic Press
备用出版商
People Post Press
备用出版商
Brooks/Cole
备用版本
Advances in imaging and electron physics, 138, Amsterdam, ©2005
备用版本
United States, United States of America
备用版本
China, People's Republic, China
备用版本
Netherlands, 2005
备用版本
October 18, 2005
元数据中的注释
producers:
Adobe PDF Library 10.0.1; modified using iTextSharpTM 5.5.10 ©2000-2016 iText Group NV (AGPL-version)
Adobe PDF Library 10.0.1; modified using iTextSharpTM 5.5.10 ©2000-2016 iText Group NV (AGPL-version)
元数据中的注释
Bookmarks: p1 (p1): 第1章 什么是团队开发
p1-1 (p2): 1.1 一个人也能进行开发
p1-2 (p3): 1.2 团队开发面临的问题
p1-3 (p4): 1.3 如何解决这些问题
p1-4 (p5): 1.4 本书的构成
p1-4-1 (p5): 1.4.1 第2章:案例分析
p1-4-2 (p5): 1.4.2 第3~5章:基础实践
p1-4-3 (p6): 1.4.3 第6~7章:持续交付和回归测试
p1-5 (p7): 1.5 阅读本书前的注意事项
p1-5-1 (p7): 1.5.1 最好的方法是具体问题具体分析
p1-5-2 (p7): 1.5.2 没有最好的工具
p2 (p9): 第2章 团队开发中发生的问题
p2-1 (p10): 2.1 案例分析的前提
p2-1-1 (p10): 2.1.1 项目的前提条件
p2-2 (p11): 2.2 案例分析(第1天)
p2-2-1 (p11): 2.2.1 问题1:重要的邮件太多,无法确定处理的优先顺序
p2-2-2 (p11): 2.2.2 问题2:没有能用于验证的环境
p2-2-3 (p12): 2.2.3 问题3:用别名目录管理分支
p2-2-4 (p14): 2.2.4 问题4:重新制作数据库比较困难
p2-3 (p16): 2.3 案例分析(第1天)中的问题点
p2-3-1 (p16): 2.3.1 问题1:重要的邮件太多,无法确定处理的优先顺序
p2-3-1-1 (p16): 邮件的数量太多,导致重要的邮件被埋没
p2-3-1-2 (p17): 无法进行状态管理
p2-3-1-3 (p17): 直观性、检索性较弱
p2-3-1-4 (p17): 用邮件来管理项目的课题
p2-3-2 (p18): 2.3.2 问题2:没有能用于验证的环境
p2-3-3 (p18): 2.3.3 问题3:用别名目录管理分支
p2-3-4 (p19): 2.3.4 问题4:重新制作数据库比较困难
p2-4 (p22): 2.4 案例分析(第2天)
p2-4-1 (p22): 2.4.1 问题5:不运行系统就无法察觉问题
p2-4-2 (p22): 2.4.2 问题6:覆盖了其他组员修正的代码
p2-4-3 (p24): 2.4.3 问题7:无法自信地进行代码重构
p2-4-4 (p25): 2.4.4 问题8:不知道bug的修正日期,也不能追踪退化
p2-4-5 (p26): 2.4.5 问题9:没有灵活使用分支和标签
p2-4-6 (p28): 2.4.6 问题10:在测试环境、正式环境上无法运行
p2-4-7 (p28): 2.4.7 问题11:发布太复杂,以至于需要发布手册
p2-5 (p30): 2.5 案例分析(第2天)中的问题点
p2-5-1 (p30): 2.5.1 问题5:不运行系统就无法察觉问题
p2-5-2 (p31): 2.5.2 问题6:覆盖了其他组员修正的代码
p2-5-3 (p31): 2.5.3 问题7:无法自信地进行代码重构
p2-5-4 (p33): 2.5.4 问题8:不知道bug的修正日期,也不能追踪退化
p2-5-5 (p35): 2.5.5 问题9:没有灵活使用分支和标签
p2-5-6 (p35): 2.5.6 问题10:在测试环境、正式环境上无法运行
p2-5-7 (p36): 2.5.7 问题11:发布太复杂,以至于需要发布手册
p2-6 (p37): 2.6 什么是理想的项目
p2-6-1 (p38): 2.6.1 使用缺陷管理系统对课题等进行统筹管理
p2-6-2 (p38): 2.6.2 尽量使用版本管理系统
p2-6-3 (p38): 2.6.3 准备可以反复验证的CI系统
p2-6-4 (p39): 2.6.4 将环境的影响控制在最小限度,并随时可以发布
p2-6-5 (p39): 2.6.5 保留所有记录以便日后追踪
p2-7 (p40): 2.7 本章总结
p3 (p41): 第3章 版本管理
p3-1 (p42): 3.1 版本管理系统
p3-1-1 (p42): 3.1.1 什么是版本管理系统
p3-1-2 (p42): 3.1.2 为什么使用版本管理系统能带来便利
p3-1-2-1 (p43): 能够保留修改内容这一最基本的记录
p3-1-2-2 (p43): 能够方便地查看版本之间的差异
p3-1-2-3 (p43): 能够防止错误地覆盖他人修改的代码
p3-1-2-4 (p44): 专栏锁模式和合并模式
p3-1-2-5 (p48): 能够还原到任意时间点的状态
p3-1-2-6 (p49): 专栏基于文件和基于变更集
p3-1-2-7 (p49): 能够生成多个派生(分支和标签),保留当时项目状态的断面
p3-2 (p51): 3.2 版本管理系统的发展变迁
p3-2-1 (p52): 3.2.1 没有版本管理系统的时代(20世纪70年代以前)
p3-2-2 (p52): 3.2.2 RCS的时代(20世纪80年代)
p3-2-3 (p52): 3.2.3 CVS的诞生(20世纪90年代)
p3-2-4 (p53): 3.2.4 VSS、Perforce等商用工具的诞生(20世纪90年代)
p3-2-5 (p54): 3.2.5 Subversion的诞生(2000年以后)
p3-2-6 (p54): 3.2.6 分布式版本管理系统的诞生(2005年以后)
p3-2-7 (p55): 3.2.7 番外篇:GitHub的诞生
p3-2-8 (p57): 3.2.8 版本管理系统的导入情况
p3-3 (p59): 3.3 分布式版本管理系统
p3-3-1 (p59): 3.3.1 使用分布式版本管理系统的5大原因
p3-3-1-1 (p59): 能将代码库完整地复制到本地
p3-3-1-2 (p59): 运行速度快
p3-3-1-3 (p59): 临时作业的提交易于管理
p3-3-1-4 (p59): 分支、合并简单方便
p3-3-1-5 (p60): 可以不受地点的限制进行协作开发
p3-3-2 (p60): 3.3.2 分布式版本管理系统的缺点
p3-3-2-1 (p60): 系统中没有真正意义上的最新版本
p3-3-2-2 (p60): 没有真正意义上的版本号
p3-3-2-3 (p61): 工作流程的配置过于灵活,容易产生混乱
p3-3-2-4 (p61): 思维方式的习惯需要一定的时间
p3-4 (p62): 3.4 如何使用版本管理系统
p3-4-1 (p62): 3.4.1 前提
p3-4-2 (p62): 3.4.2 版本管理系统管理的对象
p3-4-2-1 (p63): 代码
p3-4-2-2 (p64): 需求资料、设计资料等文档
p3-4-2-3 (p64): 数据库模式、数据
p3-4-2-4 (p64): 配置文件
p3-4-2-5 (p65): 库的依赖关系定义
p3-5 (p66): 3.5 使用Git顺利地推进并行开发
p3-5-1 (p66): 3.5.1 分支的用法
p3-5-1-1 (p66): 什么是分支
p3-5-1-2 (p66): 什么是发布分支(release branch)
p3-5-1-3 (p67): 克隆和建立分支
p3-5-1-4 (p67): 提交和提交记录
p3-5-1-5 (p68): 分支的切换
p3-5-1-6 (p69): 修正bug后的提交
p3-5-1-7 (p70): 合并到master
p3-5-1-8 (p71): 向master进行Push
p3-5-1-9 (p72): 分支使用方法总结
p3-5-2 (p72): 3.5.2 标签的使用方法
p3-5-2-1 (p72): 什么是标签
p3-5-2-2 (p72): 新建标签
p3-5-2-3 (p73): 标签的确认
p3-5-2-4 (p73): 标签的取得
p3-5-2-5 (p74): 专栏 避免使用相同的标签名和分支名
p3-5-2-6 (p75): 标签使用方法总结
p3-5-2-7 (p76): 专栏 什么是Detached HEAD
p3-6 (p77): 3.6 Git的开发流程
p3-6-1 (p77): 3.6.1 Git工作流的模式
p3-6-1-1 (p77): 中央集权型工作流
p3-6-1-2 (p78): GitHub型工作流
p3-6-2 (p79): 3.6.2 分支策略的模式
p3-6-2-1 (p79): git-flow
p3-6-2-2 (p82): github-flow
p3-6-2-3 (p83): 笔者的例子(折衷方案)
p3-6-3 (p84): 3.6.3 最合适的流程和分支策略因项目而异
p3-7 (p85): 3.7 数据库模式和数据的管理
p3-7-1 (p85): 3.7.1 需要对数据库模式进行管理的原因
p3-7-1-1 (p85): 由数据库管理员负责对修改进行管理的情况
p3-7-1-2 (p85): 修改共享数据库的模式的情况
p3-7-2 (p86): 3.7.2 应该如何管理数据库模式
p3-7-2-1 (p86): 版本管理的必要条件
p3-7-2-2 (p86): 什么是数据库迁移
p3-7-2-3 (p87): 数据库迁移的功能
p3-7-3 (p88): 3.7.3 数据库迁移工具
p3-7-3-1 (p88): Migration(Ruby on Rails)
p3-7-3-2 (p88): south(Django)
p3-7-3-3 (p89): Migrations Plugin(CakePHP)
p3-7-3-4 (p89): Evolution(Play Framework)
p3-7-4 (p89): 3.7.4 具体用法(Evolution))
p3-7-4-1 (p89): 规定
p3-7-4-2 (p90): SQL文件的执行
p3-7-4-3 (p91): 开发者之间数据库模式的同步
p3-7-4-4 (p93): 一致性问题的管理
p3-7-5 (p94): 3.7.5 数据库迁移中的注意点
p3-8 (p96): 3.8 配置文件的管理
p3-9 (p97): 3.9 依赖关系的管理
p3-9-1 (p97): 3.9.1 依赖关系管理系统
p3-9-1-1 (p97): JVM语言
p3-9-1-2 (p98): 脚本语言
p3-9-1-3 (p98): 管理依赖关系的优点
p3-10 (p100): 3.10 本章总结
p4 (p101): 第4章 缺陷管理
p4-1 (p102): 4.1 缺陷管理系统
p4-1-1 (p102): 4.1.1 项目进展不顺利的原因
p4-1-2 (p103): 4.1.2 用纸、邮件、Excel进行任务管理时的问题
p4-1-3 (p104): 4.1.3 导入缺陷管理系统的优点
p4-1-3-1 (p104): 具有任务管理所需的基本功能
p4-1-3-2 (p104): 直观性、检索性较强
p4-1-3-3 (p104): 能够对信息进行统一管理及共享
p4-1-3-4 (p105): 能够生成各类报表
p4-1-3-5 (p105): 能够和其他系统进行关联,具有可扩展性
p4-1-4 (p106): 4.1.4 什么是缺陷驱动开发
p4-1-4-1 (p106): 缺陷驱动开发的具体步骤
p4-1-4-2 (p107): 专栏彻底贯彻缺陷驱动开发的情况
p4-2 (p108): 4.2 主要的缺陷管理系统
p4-2-1 (p108): 4.2.1 OSS产品
p4-2-1-1 (p108): Trac
p4-2-1-2 (p109): Redmine
p4-2-1-3 (p110): Bugzilla
p4-2-1-4 (p111): Mantis
p4-2-2 (p112): 4.2.2 商用产品
p4-2-2-1 (p112): JIRA
p4-2-2-2 (p113): YouTRACK
p4-2-2-3 (p113): Pivotal Tracker
p4-2-2-4 (p114): Backlog
p4-2-2-5 (p115): GitHub
p4-2-3 (p116): 4.2.3 选择工具(缺陷管理系统)的要点
p4-2-4 (p117): 专栏 缺陷管理系统的应用事例
p4-3 (p118): 4.3 缺陷管理系统与版本管理系统的关联
p4-3-1 (p118): 4.3.1 通过关联实现的功能
p4-3-1-1 (p118): 从提交链接到问题票
p4-3-1-2 (p118): 从问题票链接到提交
p4-3-1-3 (p119): 提交的同时修改问题票的状态
p4-3-2 (p119): 4.3.2 关联的配置方法
p4-3-3 (p119): 4.3.3 GitHub
p4-3-3-1 (p119): GitHub的issue
p4-3-3-2 (p120): Service Hooks
p4-3-3-3 (p121): GitHub和Pivotal Tracker的关联
p4-3-3-4 (p123): GitHub和JIRA的关联
p4-3-4 (p124): 4.3.4 Trac/Redmine
p4-3-5 (p124): 4.3.5 Backlog
p4-3-5-1 (p125): Backlog和Git的关联
p4-3-5-2 (p126): Backlog和GitHub的关联
p4-3-6 (p127): 4.3.6 Git自带的Hook的使用方法
p4-4 (p128): 4.4 新功能开发、修改bug时的工作流程
p4-4-1 (p128): 4.4.1 工作流程
p4-4-1-1 (p128): 1 建立问题票
p4-4-1-2 (p129): 2 指定负责人
p4-4-1-3 (p129): 3 开发
p4-4-1-4 (p129): 4 提交
p4-4-1-5 (p129): 5 Push到代码库
p4-5 (p131): 4.5 回答“那个bug是什么时候修正的”的问题
p4-5-1 (p131): 4.5.1 Pivotal Tracker的例子
p4-5-1-1 (p131): 用记忆中残留的关键字进行检索
p4-5-1-2 (p131): 检索
p4-5-1-3 (p132): 通过问题票查找代码修改
p4-5-2 (p133): 4.5.2 Backlog的例子
p4-5-2-1 (p134): 检索
p4-6 (p136): 4.6 回答“为什么要这样修改”的问题
p4-7 (p137): 4.7 本章总结
p4-7-1 (p137): 专栏 缺陷管理、bug管理以及需求管理
p5 (p141): 第5章 CI(持续集成)
p5-1 (p142): 5.1 CI(持续集成)
p5-1-1 (p142): 5.1.1 什么是CI(持续集成)
p5-1-1-1 (p142): 集成(integration)
p5-1-1-2 (p142): 持续地进行集成就是CI
p5-1-2 (p143): 5.1.2 使开发敏捷化
p5-1-2-1 (p143): 瀑布式开发的开发阶段
p5-1-2-2 (p144): 敏捷开发的开发阶段
p5-1-3 (p147): 5.1.3 为什么要进行CI这样的实践
p5-1-3-1 (p147): 成本效益
p5-1-3-2 (p148): 市场变化的速度
p5-1-3-3 (p148): 兼顾开发速度和质量
p5-1-4 (p149): 5.1.4 CI的必要条件
p5-1-4-1 (p149): 版本管理系统
p5-1-4-2 (p149): build工具
p5-1-4-3 (p151): 测试代码
p5-1-4-4 (p151): CI工具
p5-1-5 (p151): 5.1.5 编写测试代码所需的框架
p5-1-5-1 (p151): 测试驱动开发(TDD)的框架
p5-1-5-2 (p152): 行为驱动开发(BDD)的框架
p5-1-6 (p154): 5.1.6 主要的CI工具
p5-1-6-1 (p154): Jenkins
p5-1-6-2 (p155): TravisCI
p5-2 (p157): 5.2 build工具的使用方法
p5-2-1 (p157): 5.2.1 新建工程的情况
p5-2-1-1 (p158): 建立工程雏形
p5-2-1-2 (p160): 依赖关系的定义
p5-2-1-3 (p161): 执行测试
p5-2-1-4 (p162): 导入Eclipse
p5-2-2 (p162): 5.2.2 为已有工程添加自动build功能
p5-2-3 (p163): 5.2.3 build工具的总结
p5-3 (p164): 5.3 测试代码的写法
p5-3-1 (p164): 5.3.1 作为CI的对象的测试的种类
p5-3-2 (p165): 5.3.2 何时编写测试
p5-3-2-1 (p165): 新建工程的情况
p5-3-2-2 (p165): 已有工程中没有测试的情况
p5-3-2-3 (p166): 修改bug或添加新功能的情况
p5-3-3 (p166): 5.3.3 棘手的测试该如何写
p5-3-3-1 (p166): 和外部系统有交互的测试
p5-3-3-2 (p167): 使用mocking框架进行测试
p5-3-3-3 (p168): 使用内存数据库进行测试
p5-3-3-4 (p169): 数据库变更管理和配置文件管理的测试
p5-3-3-5 (p169): UI相关的测试
p5-3-3-6 (p170): 棘手的测试要权衡工数
p5-4 (p171): 5.4 执行基于Jenkins的CI
p5-4-1 (p171): 5.4.1 Jenkins的安装
p5-4-1-1 (p172): 使用本地安装包进行安装
p5-4-2 (p172): 5.4.2 Jenkins能干些什么
p5-4-3 (p173): 5.4.3 新建任务
p5-4-4 (p173): 5.4.4 下载代码
p5-4-5 (p175): 5.4.5 自动执行build和测试
p5-4-5-1 (p175): 定期执行
p5-4-5-2 (p175): 轮询版本管理系统
p5-4-5-3 (p176): 专栏 从版本管理系统进行Push
p5-4-5-4 (p177): build的记述
p5-4-6 (p178): 5.4.6 统计结果并生成报表
p5-4-6-1 (p179): 专栏 以JUnitXML的形式输出报表比较高效
p5-4-7 (p179): 5.4.7 统计覆盖率
p5-4-7-1 (p180): 覆盖率统计工具
p5-4-7-2 (p180): Maven Cobertura插件的安装
p5-4-7-3 (p182): 专栏 Java程序库的查找方法
p5-4-7-4 (p183): Jenkins插件的配置
p5-4-8 (p184): 5.4.8 静态分析
p5-4-9 (p185): 5.4.9 配置通知
p5-5 (p187): 5.5 CI的运用
p5-5-1 (p187): 5.5.1 build失败了该怎么办
p5-5-1-1 (p187): Subversion等中央集权型版本管理系统的情况
p5-5-1-2 (p187): Git等分布式管理系统的情况
p5-5-1-3 (p188): 专栏 造成build失败后的惩罚游戏
p5-5-1-4 (p189): 测试后合并
p5-5-2 (p193): 5.5.2 确保可追溯性
p5-5-2-1 (p193): 关联build和提交
p5-5-2-2 (p194): 关联缺陷管理
p5-6 (p198): 5.6 本章总结——借助CI能够实现的事
p6 (p199): 第6章 部署的自动化(持续交付)
p6-1 (p200): 6.1 应该如何部署
p6-1-1 (p200): 6.1.1 部署自动化带来的好处
p6-1-1-1 (p200): 细粒度、频繁地发布可以使风险可控
p6-1-1-2 (p200): 能尽快地获得用户的反馈
p6-1-1-3 (p201): 团队的规模可控
p6-2 (p202): 6.2 部署的自动化
p6-2-1 (p202): 6.2.1 部署自动化方面的共识
p6-2-2 (p203): 6.2.2 部署流水线
p6-2-2-1 (p204): 通过自动化加快部署速度
p6-2-2-2 (p204): 任何人都能够实施部署是很重要的
p6-2-3 (p204): 6.2.3 服务提供工具链(provisioning tool chain)
p6-3 (p206): 6.3 引导(Bootstrapping)
p6-3-1 (p206): 6.3.1 Kickstart
p6-3-1-1 (p206): Kickstart的使用方法
p6-3-1-2 (p206): 使用时的注意事项
p6-3-1-3 (p207): Kickstart的配置示例
p6-3-2 (p208): 6.3.2 Vagrant
p6-3-2-1 (p208): 为每一位开发人员准备实体电脑比较困难
p6-3-2-2 (p209): 使用虚拟机时的注意事项
p6-3-2-3 (p209): 什么是Vagrant
p6-3-2-4 (p209): Vagrant的安装及运行方法
p6-4 (p212): 6.4 配置(Configuration)
p6-4-1 (p212): 6.4.1 不使用自动化时的问题
p6-4-2 (p213): 6.4.2 Chef
p6-4-2-1 (p213): Chef的构成
p6-4-2-2 (p215): 目录构成和文件配置
p6-4-2-3 (p215): node.json
p6-4-2-4 (p216): setup.json
p6-4-2-5 (p216): solo.rb
p6-4-2-6 (p217): default.rb
p6-4-2-7 (p218): virtualhost.conf.erb
p6-4-2-8 (p218): Chef的运行方法和运行结果
p6-4-2-9 (p219): 使用Chef的优点
p6-4-2-10 (p220): 使用Chef时的注意事项
p6-4-2-11 (p220): 使用Chef的时间点
p6-4-3 (p221): 6.4.3 serverspec
p6-4-3-1 (p221): 什么是serverspec
p6-4-3-2 (p221): serverspec的安装
p6-4-3-3 (p222): 测试文件的记述方式
p6-4-3-4 (p222): httpd_speec.rb
p6-4-3-5 (p223): git_spec.rb
p6-4-3-6 (p223): serverspec的执行方法及执行结果
p6-4-3-7 (p224): serverspec的优点
p6-4-4 (p224): 6.4.4 最佳实践(其1)
p6-4-4-1 (p226): Vagrantfile
p6-4-4-2 (p227): default.rb
p6-4-5 (p227): 6.4.5 最佳实践(其2)
p6-4-6 (p229): 6.4.6 实现物理服务器投入运营为止的所有步骤的自动化
p6-5 (p230): 6.5 编配(Orchestration)
p6-5-1 (p230): 6.5.1 发布作业的反面教材
p6-5-2 (p231): 6.5.2 Capistrano
p6-5-2-1 (p231): Capistrano的系统构成
p6-5-2-2 (p232): Capistrano的安装
p6-5-2-3 (p232): deploy.rb
p6-5-2-4 (p233): Capistrano的执行方法
p6-5-3 (p233): 6.5.3 Fabric
p6-5-3-1 (p234): Fabric(串行执行)的情况
p6-5-3-2 (p234): Capistrano(并行执行)的情况
p6-5-3-3 (p234): 理解本地服务器和远程服务器操作上的区别
p6-5-3-4 (p236): Fabric的运行方法
p6-5-4 (p237): 6.5.4 Jenkins
p6-5-4-1 (p237): 主节点(master node)和从节点(slave node)的协作
p6-5-4-2 (p238): 从节点的添加
p6-5-4-3 (p240): 任务的添加
p6-5-4-4 (p242): 任务的执行
p6-5-5 (p243): 6.5.5 最佳实践
p6-5-5-1 (p243): 结合Jenkins和Fabric
p6-5-6 (p244): 6.5.6 考虑安全问题
p6-5-6-1 (p245): 专栏 手动部署的例子
p6-6 (p247): 6.6 考虑运用相关的问题
p6-6-1 (p247): 6.6.1 不中断服务的部署方法
p6-6-2 (p247): 6.6.2 蓝绿部署(blue-green deployment)
p6-6-3 (p250): 6.6.3 云(cloud)时代的蓝绿部署
p6-6-4 (p251): 6.6.4 回滚(rollback)相关问题的考察
p6-6-4-1 (p251): 随时准备好退路
p6-6-4-2 (p251): 数据库模式的版本管理
p6-6-4-3 (p252): 回滚的验证
p6-6-4-4 (p252): 只更新代码的发布时的回滚
p6-6-4-5 (p253): 数据库模式更新时的回滚
p6-7 (p255): 6.7 本章总结
p6-7-1 (p255): 专栏 Paas的使用方式
p7 (p259): 第7章 回归测试
p7-1 (p260): 7.1 回归测试
p7-1-1 (p260): 7.1.1 什么是回归测试
p7-1-2 (p261): 7.1.2 测试分类的整理
p7-1-2-1 (p262): 支持团队的技术层面的测试(第1象限)
p7-1-2-2 (p262): 支持团队的业务层面的测试(第2象限)
p7-1-2-3 (p262): 评价产品的业务层面的测试(第3象限)
p7-1-2-4 (p263): 使用技术层面测试的产品评价(第4象限)
p7-1-3 (p263): 7.1.3 回归测试的必要性
p7-1-3-1 (p263): 退化(degrade)的发生
p7-1-3-2 (p263): 应该实现自动测试的原因
p7-1-4 (p265): 7.1.4 回归测试自动化的目标
p7-2 (p266): 7.2 Selenium
p7-2-1 (p266): 7.2.1 什么是Selenium
p7-2-2 (p266): 7.2.2 Selenium的优点
p7-2-2-1 (p266): 自动化测试用例制作简单
p7-2-2-2 (p266): 支持多种浏览器及OS
p7-2-3 (p267): 7.2.3 Selenium的组件
p7-2-3-1 (p267): Selenium IDE
p7-2-3-2 (p268): Selenium Remote Control(Selenium RC)
p7-2-3-3 (p269): Selenium WebDriver
p7-2-4 (p271): 7.2.4 测试用例的制作和执行
p7-2-4-1 (p271): Selemium IDE的安装和运行
p7-2-4-2 (p271): Selenium的测试用例
p7-2-4-3 (p274): 什么是好的测试用例
p7-2-4-4 (p274): 用Selenium Server来运行测试
p7-2-5 (p276): 7.2.5 Selenium的实际应用
p7-2-5-1 (p276): 测试页面是否有改动
p7-2-5-2 (p278): 使Selenium测试稳定运行
p7-3 (p282): 7.3 Jenkins和Selenium的协作
p7-3-1 (p282): 7.3.1 关联Jenkins和Selenium的步骤
p7-4 (p287): 7.4 Selenium测试的高速化
p7-4-1 (p288): 7.4.1 利用Jenkins的分布式构建实现测试的并行执行
p7-4-1-1 (p288): Jenkins的分布式构建的构成
p7-4-1-2 (p289): 分布式构建的配置
p7-4-2 (p291): 7.4.2 Selenium测试并行化中的难点
p7-5 (p295): 7.5 多个应用程序版本的测试
p7-5-1 (p296): 7.5.1 应用的部署
p7-5-2 (p296): 7.5.2 从版本管理系统下载测试用例
p7-5-3 (p296): 7.5.3 用Selenium测试
p7-6 (p298): 7.6 本章总结
p1-1 (p2): 1.1 一个人也能进行开发
p1-2 (p3): 1.2 团队开发面临的问题
p1-3 (p4): 1.3 如何解决这些问题
p1-4 (p5): 1.4 本书的构成
p1-4-1 (p5): 1.4.1 第2章:案例分析
p1-4-2 (p5): 1.4.2 第3~5章:基础实践
p1-4-3 (p6): 1.4.3 第6~7章:持续交付和回归测试
p1-5 (p7): 1.5 阅读本书前的注意事项
p1-5-1 (p7): 1.5.1 最好的方法是具体问题具体分析
p1-5-2 (p7): 1.5.2 没有最好的工具
p2 (p9): 第2章 团队开发中发生的问题
p2-1 (p10): 2.1 案例分析的前提
p2-1-1 (p10): 2.1.1 项目的前提条件
p2-2 (p11): 2.2 案例分析(第1天)
p2-2-1 (p11): 2.2.1 问题1:重要的邮件太多,无法确定处理的优先顺序
p2-2-2 (p11): 2.2.2 问题2:没有能用于验证的环境
p2-2-3 (p12): 2.2.3 问题3:用别名目录管理分支
p2-2-4 (p14): 2.2.4 问题4:重新制作数据库比较困难
p2-3 (p16): 2.3 案例分析(第1天)中的问题点
p2-3-1 (p16): 2.3.1 问题1:重要的邮件太多,无法确定处理的优先顺序
p2-3-1-1 (p16): 邮件的数量太多,导致重要的邮件被埋没
p2-3-1-2 (p17): 无法进行状态管理
p2-3-1-3 (p17): 直观性、检索性较弱
p2-3-1-4 (p17): 用邮件来管理项目的课题
p2-3-2 (p18): 2.3.2 问题2:没有能用于验证的环境
p2-3-3 (p18): 2.3.3 问题3:用别名目录管理分支
p2-3-4 (p19): 2.3.4 问题4:重新制作数据库比较困难
p2-4 (p22): 2.4 案例分析(第2天)
p2-4-1 (p22): 2.4.1 问题5:不运行系统就无法察觉问题
p2-4-2 (p22): 2.4.2 问题6:覆盖了其他组员修正的代码
p2-4-3 (p24): 2.4.3 问题7:无法自信地进行代码重构
p2-4-4 (p25): 2.4.4 问题8:不知道bug的修正日期,也不能追踪退化
p2-4-5 (p26): 2.4.5 问题9:没有灵活使用分支和标签
p2-4-6 (p28): 2.4.6 问题10:在测试环境、正式环境上无法运行
p2-4-7 (p28): 2.4.7 问题11:发布太复杂,以至于需要发布手册
p2-5 (p30): 2.5 案例分析(第2天)中的问题点
p2-5-1 (p30): 2.5.1 问题5:不运行系统就无法察觉问题
p2-5-2 (p31): 2.5.2 问题6:覆盖了其他组员修正的代码
p2-5-3 (p31): 2.5.3 问题7:无法自信地进行代码重构
p2-5-4 (p33): 2.5.4 问题8:不知道bug的修正日期,也不能追踪退化
p2-5-5 (p35): 2.5.5 问题9:没有灵活使用分支和标签
p2-5-6 (p35): 2.5.6 问题10:在测试环境、正式环境上无法运行
p2-5-7 (p36): 2.5.7 问题11:发布太复杂,以至于需要发布手册
p2-6 (p37): 2.6 什么是理想的项目
p2-6-1 (p38): 2.6.1 使用缺陷管理系统对课题等进行统筹管理
p2-6-2 (p38): 2.6.2 尽量使用版本管理系统
p2-6-3 (p38): 2.6.3 准备可以反复验证的CI系统
p2-6-4 (p39): 2.6.4 将环境的影响控制在最小限度,并随时可以发布
p2-6-5 (p39): 2.6.5 保留所有记录以便日后追踪
p2-7 (p40): 2.7 本章总结
p3 (p41): 第3章 版本管理
p3-1 (p42): 3.1 版本管理系统
p3-1-1 (p42): 3.1.1 什么是版本管理系统
p3-1-2 (p42): 3.1.2 为什么使用版本管理系统能带来便利
p3-1-2-1 (p43): 能够保留修改内容这一最基本的记录
p3-1-2-2 (p43): 能够方便地查看版本之间的差异
p3-1-2-3 (p43): 能够防止错误地覆盖他人修改的代码
p3-1-2-4 (p44): 专栏锁模式和合并模式
p3-1-2-5 (p48): 能够还原到任意时间点的状态
p3-1-2-6 (p49): 专栏基于文件和基于变更集
p3-1-2-7 (p49): 能够生成多个派生(分支和标签),保留当时项目状态的断面
p3-2 (p51): 3.2 版本管理系统的发展变迁
p3-2-1 (p52): 3.2.1 没有版本管理系统的时代(20世纪70年代以前)
p3-2-2 (p52): 3.2.2 RCS的时代(20世纪80年代)
p3-2-3 (p52): 3.2.3 CVS的诞生(20世纪90年代)
p3-2-4 (p53): 3.2.4 VSS、Perforce等商用工具的诞生(20世纪90年代)
p3-2-5 (p54): 3.2.5 Subversion的诞生(2000年以后)
p3-2-6 (p54): 3.2.6 分布式版本管理系统的诞生(2005年以后)
p3-2-7 (p55): 3.2.7 番外篇:GitHub的诞生
p3-2-8 (p57): 3.2.8 版本管理系统的导入情况
p3-3 (p59): 3.3 分布式版本管理系统
p3-3-1 (p59): 3.3.1 使用分布式版本管理系统的5大原因
p3-3-1-1 (p59): 能将代码库完整地复制到本地
p3-3-1-2 (p59): 运行速度快
p3-3-1-3 (p59): 临时作业的提交易于管理
p3-3-1-4 (p59): 分支、合并简单方便
p3-3-1-5 (p60): 可以不受地点的限制进行协作开发
p3-3-2 (p60): 3.3.2 分布式版本管理系统的缺点
p3-3-2-1 (p60): 系统中没有真正意义上的最新版本
p3-3-2-2 (p60): 没有真正意义上的版本号
p3-3-2-3 (p61): 工作流程的配置过于灵活,容易产生混乱
p3-3-2-4 (p61): 思维方式的习惯需要一定的时间
p3-4 (p62): 3.4 如何使用版本管理系统
p3-4-1 (p62): 3.4.1 前提
p3-4-2 (p62): 3.4.2 版本管理系统管理的对象
p3-4-2-1 (p63): 代码
p3-4-2-2 (p64): 需求资料、设计资料等文档
p3-4-2-3 (p64): 数据库模式、数据
p3-4-2-4 (p64): 配置文件
p3-4-2-5 (p65): 库的依赖关系定义
p3-5 (p66): 3.5 使用Git顺利地推进并行开发
p3-5-1 (p66): 3.5.1 分支的用法
p3-5-1-1 (p66): 什么是分支
p3-5-1-2 (p66): 什么是发布分支(release branch)
p3-5-1-3 (p67): 克隆和建立分支
p3-5-1-4 (p67): 提交和提交记录
p3-5-1-5 (p68): 分支的切换
p3-5-1-6 (p69): 修正bug后的提交
p3-5-1-7 (p70): 合并到master
p3-5-1-8 (p71): 向master进行Push
p3-5-1-9 (p72): 分支使用方法总结
p3-5-2 (p72): 3.5.2 标签的使用方法
p3-5-2-1 (p72): 什么是标签
p3-5-2-2 (p72): 新建标签
p3-5-2-3 (p73): 标签的确认
p3-5-2-4 (p73): 标签的取得
p3-5-2-5 (p74): 专栏 避免使用相同的标签名和分支名
p3-5-2-6 (p75): 标签使用方法总结
p3-5-2-7 (p76): 专栏 什么是Detached HEAD
p3-6 (p77): 3.6 Git的开发流程
p3-6-1 (p77): 3.6.1 Git工作流的模式
p3-6-1-1 (p77): 中央集权型工作流
p3-6-1-2 (p78): GitHub型工作流
p3-6-2 (p79): 3.6.2 分支策略的模式
p3-6-2-1 (p79): git-flow
p3-6-2-2 (p82): github-flow
p3-6-2-3 (p83): 笔者的例子(折衷方案)
p3-6-3 (p84): 3.6.3 最合适的流程和分支策略因项目而异
p3-7 (p85): 3.7 数据库模式和数据的管理
p3-7-1 (p85): 3.7.1 需要对数据库模式进行管理的原因
p3-7-1-1 (p85): 由数据库管理员负责对修改进行管理的情况
p3-7-1-2 (p85): 修改共享数据库的模式的情况
p3-7-2 (p86): 3.7.2 应该如何管理数据库模式
p3-7-2-1 (p86): 版本管理的必要条件
p3-7-2-2 (p86): 什么是数据库迁移
p3-7-2-3 (p87): 数据库迁移的功能
p3-7-3 (p88): 3.7.3 数据库迁移工具
p3-7-3-1 (p88): Migration(Ruby on Rails)
p3-7-3-2 (p88): south(Django)
p3-7-3-3 (p89): Migrations Plugin(CakePHP)
p3-7-3-4 (p89): Evolution(Play Framework)
p3-7-4 (p89): 3.7.4 具体用法(Evolution))
p3-7-4-1 (p89): 规定
p3-7-4-2 (p90): SQL文件的执行
p3-7-4-3 (p91): 开发者之间数据库模式的同步
p3-7-4-4 (p93): 一致性问题的管理
p3-7-5 (p94): 3.7.5 数据库迁移中的注意点
p3-8 (p96): 3.8 配置文件的管理
p3-9 (p97): 3.9 依赖关系的管理
p3-9-1 (p97): 3.9.1 依赖关系管理系统
p3-9-1-1 (p97): JVM语言
p3-9-1-2 (p98): 脚本语言
p3-9-1-3 (p98): 管理依赖关系的优点
p3-10 (p100): 3.10 本章总结
p4 (p101): 第4章 缺陷管理
p4-1 (p102): 4.1 缺陷管理系统
p4-1-1 (p102): 4.1.1 项目进展不顺利的原因
p4-1-2 (p103): 4.1.2 用纸、邮件、Excel进行任务管理时的问题
p4-1-3 (p104): 4.1.3 导入缺陷管理系统的优点
p4-1-3-1 (p104): 具有任务管理所需的基本功能
p4-1-3-2 (p104): 直观性、检索性较强
p4-1-3-3 (p104): 能够对信息进行统一管理及共享
p4-1-3-4 (p105): 能够生成各类报表
p4-1-3-5 (p105): 能够和其他系统进行关联,具有可扩展性
p4-1-4 (p106): 4.1.4 什么是缺陷驱动开发
p4-1-4-1 (p106): 缺陷驱动开发的具体步骤
p4-1-4-2 (p107): 专栏彻底贯彻缺陷驱动开发的情况
p4-2 (p108): 4.2 主要的缺陷管理系统
p4-2-1 (p108): 4.2.1 OSS产品
p4-2-1-1 (p108): Trac
p4-2-1-2 (p109): Redmine
p4-2-1-3 (p110): Bugzilla
p4-2-1-4 (p111): Mantis
p4-2-2 (p112): 4.2.2 商用产品
p4-2-2-1 (p112): JIRA
p4-2-2-2 (p113): YouTRACK
p4-2-2-3 (p113): Pivotal Tracker
p4-2-2-4 (p114): Backlog
p4-2-2-5 (p115): GitHub
p4-2-3 (p116): 4.2.3 选择工具(缺陷管理系统)的要点
p4-2-4 (p117): 专栏 缺陷管理系统的应用事例
p4-3 (p118): 4.3 缺陷管理系统与版本管理系统的关联
p4-3-1 (p118): 4.3.1 通过关联实现的功能
p4-3-1-1 (p118): 从提交链接到问题票
p4-3-1-2 (p118): 从问题票链接到提交
p4-3-1-3 (p119): 提交的同时修改问题票的状态
p4-3-2 (p119): 4.3.2 关联的配置方法
p4-3-3 (p119): 4.3.3 GitHub
p4-3-3-1 (p119): GitHub的issue
p4-3-3-2 (p120): Service Hooks
p4-3-3-3 (p121): GitHub和Pivotal Tracker的关联
p4-3-3-4 (p123): GitHub和JIRA的关联
p4-3-4 (p124): 4.3.4 Trac/Redmine
p4-3-5 (p124): 4.3.5 Backlog
p4-3-5-1 (p125): Backlog和Git的关联
p4-3-5-2 (p126): Backlog和GitHub的关联
p4-3-6 (p127): 4.3.6 Git自带的Hook的使用方法
p4-4 (p128): 4.4 新功能开发、修改bug时的工作流程
p4-4-1 (p128): 4.4.1 工作流程
p4-4-1-1 (p128): 1 建立问题票
p4-4-1-2 (p129): 2 指定负责人
p4-4-1-3 (p129): 3 开发
p4-4-1-4 (p129): 4 提交
p4-4-1-5 (p129): 5 Push到代码库
p4-5 (p131): 4.5 回答“那个bug是什么时候修正的”的问题
p4-5-1 (p131): 4.5.1 Pivotal Tracker的例子
p4-5-1-1 (p131): 用记忆中残留的关键字进行检索
p4-5-1-2 (p131): 检索
p4-5-1-3 (p132): 通过问题票查找代码修改
p4-5-2 (p133): 4.5.2 Backlog的例子
p4-5-2-1 (p134): 检索
p4-6 (p136): 4.6 回答“为什么要这样修改”的问题
p4-7 (p137): 4.7 本章总结
p4-7-1 (p137): 专栏 缺陷管理、bug管理以及需求管理
p5 (p141): 第5章 CI(持续集成)
p5-1 (p142): 5.1 CI(持续集成)
p5-1-1 (p142): 5.1.1 什么是CI(持续集成)
p5-1-1-1 (p142): 集成(integration)
p5-1-1-2 (p142): 持续地进行集成就是CI
p5-1-2 (p143): 5.1.2 使开发敏捷化
p5-1-2-1 (p143): 瀑布式开发的开发阶段
p5-1-2-2 (p144): 敏捷开发的开发阶段
p5-1-3 (p147): 5.1.3 为什么要进行CI这样的实践
p5-1-3-1 (p147): 成本效益
p5-1-3-2 (p148): 市场变化的速度
p5-1-3-3 (p148): 兼顾开发速度和质量
p5-1-4 (p149): 5.1.4 CI的必要条件
p5-1-4-1 (p149): 版本管理系统
p5-1-4-2 (p149): build工具
p5-1-4-3 (p151): 测试代码
p5-1-4-4 (p151): CI工具
p5-1-5 (p151): 5.1.5 编写测试代码所需的框架
p5-1-5-1 (p151): 测试驱动开发(TDD)的框架
p5-1-5-2 (p152): 行为驱动开发(BDD)的框架
p5-1-6 (p154): 5.1.6 主要的CI工具
p5-1-6-1 (p154): Jenkins
p5-1-6-2 (p155): TravisCI
p5-2 (p157): 5.2 build工具的使用方法
p5-2-1 (p157): 5.2.1 新建工程的情况
p5-2-1-1 (p158): 建立工程雏形
p5-2-1-2 (p160): 依赖关系的定义
p5-2-1-3 (p161): 执行测试
p5-2-1-4 (p162): 导入Eclipse
p5-2-2 (p162): 5.2.2 为已有工程添加自动build功能
p5-2-3 (p163): 5.2.3 build工具的总结
p5-3 (p164): 5.3 测试代码的写法
p5-3-1 (p164): 5.3.1 作为CI的对象的测试的种类
p5-3-2 (p165): 5.3.2 何时编写测试
p5-3-2-1 (p165): 新建工程的情况
p5-3-2-2 (p165): 已有工程中没有测试的情况
p5-3-2-3 (p166): 修改bug或添加新功能的情况
p5-3-3 (p166): 5.3.3 棘手的测试该如何写
p5-3-3-1 (p166): 和外部系统有交互的测试
p5-3-3-2 (p167): 使用mocking框架进行测试
p5-3-3-3 (p168): 使用内存数据库进行测试
p5-3-3-4 (p169): 数据库变更管理和配置文件管理的测试
p5-3-3-5 (p169): UI相关的测试
p5-3-3-6 (p170): 棘手的测试要权衡工数
p5-4 (p171): 5.4 执行基于Jenkins的CI
p5-4-1 (p171): 5.4.1 Jenkins的安装
p5-4-1-1 (p172): 使用本地安装包进行安装
p5-4-2 (p172): 5.4.2 Jenkins能干些什么
p5-4-3 (p173): 5.4.3 新建任务
p5-4-4 (p173): 5.4.4 下载代码
p5-4-5 (p175): 5.4.5 自动执行build和测试
p5-4-5-1 (p175): 定期执行
p5-4-5-2 (p175): 轮询版本管理系统
p5-4-5-3 (p176): 专栏 从版本管理系统进行Push
p5-4-5-4 (p177): build的记述
p5-4-6 (p178): 5.4.6 统计结果并生成报表
p5-4-6-1 (p179): 专栏 以JUnitXML的形式输出报表比较高效
p5-4-7 (p179): 5.4.7 统计覆盖率
p5-4-7-1 (p180): 覆盖率统计工具
p5-4-7-2 (p180): Maven Cobertura插件的安装
p5-4-7-3 (p182): 专栏 Java程序库的查找方法
p5-4-7-4 (p183): Jenkins插件的配置
p5-4-8 (p184): 5.4.8 静态分析
p5-4-9 (p185): 5.4.9 配置通知
p5-5 (p187): 5.5 CI的运用
p5-5-1 (p187): 5.5.1 build失败了该怎么办
p5-5-1-1 (p187): Subversion等中央集权型版本管理系统的情况
p5-5-1-2 (p187): Git等分布式管理系统的情况
p5-5-1-3 (p188): 专栏 造成build失败后的惩罚游戏
p5-5-1-4 (p189): 测试后合并
p5-5-2 (p193): 5.5.2 确保可追溯性
p5-5-2-1 (p193): 关联build和提交
p5-5-2-2 (p194): 关联缺陷管理
p5-6 (p198): 5.6 本章总结——借助CI能够实现的事
p6 (p199): 第6章 部署的自动化(持续交付)
p6-1 (p200): 6.1 应该如何部署
p6-1-1 (p200): 6.1.1 部署自动化带来的好处
p6-1-1-1 (p200): 细粒度、频繁地发布可以使风险可控
p6-1-1-2 (p200): 能尽快地获得用户的反馈
p6-1-1-3 (p201): 团队的规模可控
p6-2 (p202): 6.2 部署的自动化
p6-2-1 (p202): 6.2.1 部署自动化方面的共识
p6-2-2 (p203): 6.2.2 部署流水线
p6-2-2-1 (p204): 通过自动化加快部署速度
p6-2-2-2 (p204): 任何人都能够实施部署是很重要的
p6-2-3 (p204): 6.2.3 服务提供工具链(provisioning tool chain)
p6-3 (p206): 6.3 引导(Bootstrapping)
p6-3-1 (p206): 6.3.1 Kickstart
p6-3-1-1 (p206): Kickstart的使用方法
p6-3-1-2 (p206): 使用时的注意事项
p6-3-1-3 (p207): Kickstart的配置示例
p6-3-2 (p208): 6.3.2 Vagrant
p6-3-2-1 (p208): 为每一位开发人员准备实体电脑比较困难
p6-3-2-2 (p209): 使用虚拟机时的注意事项
p6-3-2-3 (p209): 什么是Vagrant
p6-3-2-4 (p209): Vagrant的安装及运行方法
p6-4 (p212): 6.4 配置(Configuration)
p6-4-1 (p212): 6.4.1 不使用自动化时的问题
p6-4-2 (p213): 6.4.2 Chef
p6-4-2-1 (p213): Chef的构成
p6-4-2-2 (p215): 目录构成和文件配置
p6-4-2-3 (p215): node.json
p6-4-2-4 (p216): setup.json
p6-4-2-5 (p216): solo.rb
p6-4-2-6 (p217): default.rb
p6-4-2-7 (p218): virtualhost.conf.erb
p6-4-2-8 (p218): Chef的运行方法和运行结果
p6-4-2-9 (p219): 使用Chef的优点
p6-4-2-10 (p220): 使用Chef时的注意事项
p6-4-2-11 (p220): 使用Chef的时间点
p6-4-3 (p221): 6.4.3 serverspec
p6-4-3-1 (p221): 什么是serverspec
p6-4-3-2 (p221): serverspec的安装
p6-4-3-3 (p222): 测试文件的记述方式
p6-4-3-4 (p222): httpd_speec.rb
p6-4-3-5 (p223): git_spec.rb
p6-4-3-6 (p223): serverspec的执行方法及执行结果
p6-4-3-7 (p224): serverspec的优点
p6-4-4 (p224): 6.4.4 最佳实践(其1)
p6-4-4-1 (p226): Vagrantfile
p6-4-4-2 (p227): default.rb
p6-4-5 (p227): 6.4.5 最佳实践(其2)
p6-4-6 (p229): 6.4.6 实现物理服务器投入运营为止的所有步骤的自动化
p6-5 (p230): 6.5 编配(Orchestration)
p6-5-1 (p230): 6.5.1 发布作业的反面教材
p6-5-2 (p231): 6.5.2 Capistrano
p6-5-2-1 (p231): Capistrano的系统构成
p6-5-2-2 (p232): Capistrano的安装
p6-5-2-3 (p232): deploy.rb
p6-5-2-4 (p233): Capistrano的执行方法
p6-5-3 (p233): 6.5.3 Fabric
p6-5-3-1 (p234): Fabric(串行执行)的情况
p6-5-3-2 (p234): Capistrano(并行执行)的情况
p6-5-3-3 (p234): 理解本地服务器和远程服务器操作上的区别
p6-5-3-4 (p236): Fabric的运行方法
p6-5-4 (p237): 6.5.4 Jenkins
p6-5-4-1 (p237): 主节点(master node)和从节点(slave node)的协作
p6-5-4-2 (p238): 从节点的添加
p6-5-4-3 (p240): 任务的添加
p6-5-4-4 (p242): 任务的执行
p6-5-5 (p243): 6.5.5 最佳实践
p6-5-5-1 (p243): 结合Jenkins和Fabric
p6-5-6 (p244): 6.5.6 考虑安全问题
p6-5-6-1 (p245): 专栏 手动部署的例子
p6-6 (p247): 6.6 考虑运用相关的问题
p6-6-1 (p247): 6.6.1 不中断服务的部署方法
p6-6-2 (p247): 6.6.2 蓝绿部署(blue-green deployment)
p6-6-3 (p250): 6.6.3 云(cloud)时代的蓝绿部署
p6-6-4 (p251): 6.6.4 回滚(rollback)相关问题的考察
p6-6-4-1 (p251): 随时准备好退路
p6-6-4-2 (p251): 数据库模式的版本管理
p6-6-4-3 (p252): 回滚的验证
p6-6-4-4 (p252): 只更新代码的发布时的回滚
p6-6-4-5 (p253): 数据库模式更新时的回滚
p6-7 (p255): 6.7 本章总结
p6-7-1 (p255): 专栏 Paas的使用方式
p7 (p259): 第7章 回归测试
p7-1 (p260): 7.1 回归测试
p7-1-1 (p260): 7.1.1 什么是回归测试
p7-1-2 (p261): 7.1.2 测试分类的整理
p7-1-2-1 (p262): 支持团队的技术层面的测试(第1象限)
p7-1-2-2 (p262): 支持团队的业务层面的测试(第2象限)
p7-1-2-3 (p262): 评价产品的业务层面的测试(第3象限)
p7-1-2-4 (p263): 使用技术层面测试的产品评价(第4象限)
p7-1-3 (p263): 7.1.3 回归测试的必要性
p7-1-3-1 (p263): 退化(degrade)的发生
p7-1-3-2 (p263): 应该实现自动测试的原因
p7-1-4 (p265): 7.1.4 回归测试自动化的目标
p7-2 (p266): 7.2 Selenium
p7-2-1 (p266): 7.2.1 什么是Selenium
p7-2-2 (p266): 7.2.2 Selenium的优点
p7-2-2-1 (p266): 自动化测试用例制作简单
p7-2-2-2 (p266): 支持多种浏览器及OS
p7-2-3 (p267): 7.2.3 Selenium的组件
p7-2-3-1 (p267): Selenium IDE
p7-2-3-2 (p268): Selenium Remote Control(Selenium RC)
p7-2-3-3 (p269): Selenium WebDriver
p7-2-4 (p271): 7.2.4 测试用例的制作和执行
p7-2-4-1 (p271): Selemium IDE的安装和运行
p7-2-4-2 (p271): Selenium的测试用例
p7-2-4-3 (p274): 什么是好的测试用例
p7-2-4-4 (p274): 用Selenium Server来运行测试
p7-2-5 (p276): 7.2.5 Selenium的实际应用
p7-2-5-1 (p276): 测试页面是否有改动
p7-2-5-2 (p278): 使Selenium测试稳定运行
p7-3 (p282): 7.3 Jenkins和Selenium的协作
p7-3-1 (p282): 7.3.1 关联Jenkins和Selenium的步骤
p7-4 (p287): 7.4 Selenium测试的高速化
p7-4-1 (p288): 7.4.1 利用Jenkins的分布式构建实现测试的并行执行
p7-4-1-1 (p288): Jenkins的分布式构建的构成
p7-4-1-2 (p289): 分布式构建的配置
p7-4-2 (p291): 7.4.2 Selenium测试并行化中的难点
p7-5 (p295): 7.5 多个应用程序版本的测试
p7-5-1 (p296): 7.5.1 应用的部署
p7-5-2 (p296): 7.5.2 从版本管理系统下载测试用例
p7-5-3 (p296): 7.5.3 用Selenium测试
p7-6 (p298): 7.6 本章总结
元数据中的注释
РГБ
元数据中的注释
Russian State Library [rgb] MARC:
=001 002775329
=005 20051208092402.0
=008 051205s2005\\\\ne\||||\\\\\\\0||\|\eng|d
=017 \\ $a ИП12527-05 $b РГБ
=020 \\ $a 0-12-014780-7
=040 \\ $a RuMoRGB $b rus $e rcr
=041 0\ $a eng
=044 \\ $a xxu
=245 00 $a Vol. 138
=260 \\ $c 2005
=300 \\ $a XVII, 371 с. $b ил., табл.
=773 18 $t Advances in imaging and electron physics $g Vol. 138
=852 4\ $a РГБ $b FB $j 25 25/20-8 $x 80
=001 002775329
=005 20051208092402.0
=008 051205s2005\\\\ne\||||\\\\\\\0||\|\eng|d
=017 \\ $a ИП12527-05 $b РГБ
=020 \\ $a 0-12-014780-7
=040 \\ $a RuMoRGB $b rus $e rcr
=041 0\ $a eng
=044 \\ $a xxu
=245 00 $a Vol. 138
=260 \\ $c 2005
=300 \\ $a XVII, 371 с. $b ил., табл.
=773 18 $t Advances in imaging and electron physics $g Vol. 138
=852 4\ $a РГБ $b FB $j 25 25/20-8 $x 80
备用描述
Ben shu yi tuan dui kai fa zhong suo bi yao de gong ju de dao ru fang fa he shi yong fang fa wei he xin, dui tuan dui kai fa de zheng ti jie gou jin xing gai kuo xing de shuo ming . nei rong she ji tuan dui kai fa zhong fa sheng de wen ti, ban ben guan li, que xian guan li, CI (chi xu ji cheng), bu shu de zi dong hua (chi xu fa bu) yi ji hui gui ce shi, bing qie dui " wei shi me yong na ge gong ju "" wei shi me yao zhe yang shi yong " deng kai fa xian chang chang you de wen ti jin xing ju li shuo ming
备用描述
Discussing spectral color spaces, this book covers phase contrast enhancement with phase plates in electron microscopy. It features articles on the physics of electron devices, particle optics at high and low energies, microlithography, image science and digital image processing, electromagnetic wave propagation, electron microscopy, and more.
备用描述
本书以团队开发中所必需的工具的导入方法和使用方法为核心,对团队开发的整体结构进行概括性的说明.内容涉及团队开发中发生的问题,版本管理系统,缺陷管理系统,持续集成,持续交付以及回归测试,并且对"为什么用那个工具""为什么要这样使用"等开发现场常有的问题进行举例说明
开源日期
2022-08-07
🚀 快速下载
成为会员以支持书籍、论文等的长期保存。为了感谢您对我们的支持,您将获得高速下载权益。❤️
如果您在本月捐款,您将获得双倍的快速下载次数。
🐢 低速下载
由可信的合作方提供。 更多信息请参见常见问题解答。 (可能需要验证浏览器——无限次下载!)
- 低速服务器(合作方提供) #1 (稍快但需要排队)
- 低速服务器(合作方提供) #2 (稍快但需要排队)
- 低速服务器(合作方提供) #3 (稍快但需要排队)
- 低速服务器(合作方提供) #4 (稍快但需要排队)
- 低速服务器(合作方提供) #5 (无需排队,但可能非常慢)
- 低速服务器(合作方提供) #6 (无需排队,但可能非常慢)
- 低速服务器(合作方提供) #7 (无需排队,但可能非常慢)
- 低速服务器(合作方提供) #8 (无需排队,但可能非常慢)
- 低速服务器(合作方提供) #9 (无需排队,但可能非常慢)
- 下载后: 在我们的查看器中打开
所有选项下载的文件都相同,应该可以安全使用。即使这样,从互联网下载文件时始终要小心。例如,确保您的设备更新及时。
外部下载
-
对于大文件,我们建议使用下载管理器以防止中断。
推荐的下载管理器:JDownloader -
您将需要一个电子书或 PDF 阅读器来打开文件,具体取决于文件格式。
推荐的电子书阅读器:Anna的档案在线查看器、ReadEra和Calibre -
使用在线工具进行格式转换。
推荐的转换工具:CloudConvert和PrintFriendly -
您可以将 PDF 和 EPUB 文件发送到您的 Kindle 或 Kobo 电子阅读器。
推荐的工具:亚马逊的“发送到 Kindle”和djazz 的“发送到 Kobo/Kindle” -
支持作者和图书馆
✍️ 如果您喜欢这个并且能够负担得起,请考虑购买原版,或直接支持作者。
📚 如果您当地的图书馆有这本书,请考虑在那里免费借阅。
下面的文字仅以英文继续。
总下载量:
“文件的MD5”是根据文件内容计算出的哈希值,并且基于该内容具有相当的唯一性。我们这里索引的所有影子图书馆都主要使用MD5来标识文件。
一个文件可能会出现在多个影子图书馆中。有关我们编译的各种数据集的信息,请参见数据集页面。
有关此文件的详细信息,请查看其JSON 文件。 Live/debug JSON version. Live/debug page.