高效团队开发:工具与方法

高效团队开发:工具与方法

致中文版的读者

1 什么是团队开发

1.1 一个人也能进行开发

1.2 团队开发面临的问题

1.3 如何解决这些问题

1.4 如何解决这些问题

1.4.1 2 :案例分析
1.4.2 3~5 :基础实践
1.4.3 6~7 :持续交付和回归测试

1.5 阅读本书前的注意事项

1.5.1 最好的方法是具体问题具体分析
1.5.2 没有最好的工具

2 团队开发中发生的问题

2.1 案例分析的前提

2.1.1 项目的前提条件

2.2 案例分析(第1天)

2.2.1 问题1 :重要的邮件太多,无法确定处理的优先顺序
2.2.2 问题2 :没有能用于验证的环境
2.2.3 问题3 :用别名目录管理分支
2.2.4 问题4 :重新制作数据库比较困难

2.3 案例分析(第1天)中的问题点

2.3.1 问题1 :重要的邮件太多,无法确定处理的优先顺序
● …… 邮件的数量太多,导致重要的邮件被埋没
●…… 无法进行状态管理
●…… 直观性、检索性较弱
●…… 用邮件来管理项目的课题
2.3.2 问题2 :没有能用于验证的环境
2.3.3 问题3 :用别名目录管理分支
2.3.4 问题4 :重新制作数据库比较困难

2.4 案例分析(第2天)

2.4.1 问题5 :不运行系统就无法察觉问题
2.4.2 问题6 :覆盖了其他组员修正的代码
2.4.3 问题7 :无法自信地进行代码重构
2.4.4 问题8 :不知道 bug 的修正日期,也不能追踪退化
2.4.5 问题9 :没有灵活使用分支和标签
2.4.6 问题10 :在测试环境、正式环境上无法运行
2.4.7 问题11 :发布太复杂,以至于需要发布手册

2.5 案例分析(第2天)中的问题点

2.5.1 问题5 :不运行系统就无法察觉问题
2.5.2 问题6 :覆盖了其他组员修正的代码
2.5.3 问题7 :无法自信地进行代码重构
2.5.4 问题8 :不知道 bug 的修正日期,也不能追踪退化
2.5.5 问题9 :没有灵活使用分支和标签
2.5.6 问题10 :在测试环境、正式环境上无法运行
2.5.7 问题11 :发布太复杂,以至于需要发布手册

2.6 什么是理想的项目

3 版本管理

3.1 版本管理系统

3.1.1 什么是版本管理系统
3.1.2 为什么使用版本管理系统能带来便利
●…… 能够保留修改内容这一最基本的记录
●…… 能够方便地查看版本之间的差异
●…… 能够防止错误地覆盖他人修改的代码
●…… 能够还原到任意时间点的状态
●…… 能够生成多个派生(分支和标签),保留当时项目状态的断面

3.2 版本管理系统的发展变迁

3.2.1 没有版本管理系统的时代(20世纪70年代以前)
3.2.2 RCS 的时代(20世纪80年代)
3.2.3 CVS 的诞生(20世纪90年代)
3.2.4 VSS、Perforce 等商用工具的诞生(20世纪90年代)
3.2.5 Subversion 的诞生(2000年以后)
3.2.6 分布式版本管理系统的诞生(2005年以后)
3.2.7 番外篇 :GitHub 的诞生
3.2.8 版本管理系统的导入情况

3.3 分布式版本管理系统

3.3.1 使用分布式版本管理系统的5大原因
●…… 能将代码库完整地复制到本地
●…… 运行速度快
●…… 临时作业的提交易于管理
●…… 分支、合并简单方便
●…… 可以不受地点的限制进行协作开发
3.3.2 分布式版本管理系统的缺点
●…… 系统中没有真正意义上的最新版本
●…… 没有真正意义上的版本号
●…… 工作流程的配置过于灵活,容易产生混乱
●…… 思维方式的习惯需要一定的时间

3.4 如何使用版本管理系统

3.4.1 前提
3.4.2 版本管理系统管理的对象
●…… 代码
●…… 需求资料、设计资料等文档
●…… 数据库模式、数据
●…… 配置文件
●…… 库的依赖关系定义

3.5 使用 Git 顺利地推进并行开发

3.5.1 分支的用法
●…… 什么是分支
●…… 什么是发布分支(release branch)
●…… 克隆和建立分支
●…… 提交和提交记录
●…… 分支的切换
●…… 修正 bug 后的提交
●…… 合并到 master
●…… 向 master 进行 Push
●…… 分支使用方法总结
3.5.2 标签的使用方法
●…… 什么是标签
●…… 新建标签
●…… 标签的确认
●…… 标签的取得
●…… 标签使用方法总结

3.6 Git 的开发流程

3.6.1 Git 工作流的模式
●…… 中央集权型工作流
●…… GitHub 型工作流
3.6.2 分支策略的模式
●…… git-flow
●…… github-flow
●…… 笔者的例子(折衷方案)
3.6.3 最合适的流程和分支策略因项目而异

3.7 数据库模式和数据的管理

3.7.1 需要对数据库模式进行管理的原因
●…… 由数据库管理员负责对修改进行管理的情况
●…… 修改共享数据库的模式的情况
3.7.2 应该如何管理数据库模式
●…… 版本管理的必要条件
●…… 什么是数据库迁移
●…… 数据库迁移的功能
3.7.3 数据库迁移工具
●…… Migration(Ruby on Rails)
●…… south(Django)
●…… Migrations Plugin(CakePHP)
●…… Evolution(Play Framework)
3.7.4 具体用法(Evolution)
●…… 规定
●…… SQL 文件的执行
●…… 开发者之间数据库模式的同步
●…… 一致性问题的管理
3.7.5 数据库迁移中的注意点

3.8 配置文件的管理

3.9 依赖关系的管理

3.9.1 依赖关系管理系统
●…… JVM 语言
●…… 脚本语言
●…… 管理依赖关系的优点

3.10 本章总结

4 缺陷管理

4.1 缺陷管理系统

4.1.1 项目进展不顺利的原因
4.1.2 用纸、邮件、Excel 进行任务管理时的问题
4.1.3 导入缺陷管理系统的优点
●…… 具有任务管理所需的基本功能
●…… 直观性、检索性较强
●…… 能够对信息进行统一管理及共享
●…… 能够生成各类报表
●…… 能够和其他系统进行关联,具有可扩展性
4.1.4 什么是缺陷驱动开发
●…… 缺陷驱动开发的具体步骤

4.2 主要的缺陷管理系统

4.2.1 OSS 产品
●…… Trac
●…… Redmine
●…… Bugzilla
●…… Mantis
4.2.2 商用产品
●…… JIRA
●…… YouTRACK
●…… Pivotal Tracker
●…… Backlog
●…… GitHub
4.2.3 选择工具(缺陷管理系统)的要点

4.3 缺陷管理系统与版本管理系统的关联

4.3.1 通过关联实现的功能
●…… 从提交链接到问题票
●…… 从问题票链接到提交
●…… 提交的同时修改问题票的状态
4.3.2 关联的配置方法
4.3.3 GitHub
●…… GitHub 的 issue
●…… Service Hooks
●…… GitHub 和 Pivotal Tracker 的关联
●…… GitHub 和 JIRA 的关联
4.3.4 Trac/Redmine
4.3.5 Backlog
●…… Backlog 和 Git 的关联
●…… Backlog和 GitHub 的关联
4.3.6 Git 自带的 Hook 的使用方法

4.4 新功能开发、修改 bug 时的工作流程

4.4.1 工作流程
●…… ❶ 建立问题票
●…… ❷ 指定负责人
●…… ❸ 开发
●…… ❹ 提交
●…… ❺ Push 到代码库

4.5 回答“那个 bug 是什么时候修正的”的问题

4.5.1 Pivotal Tracker 的例子
●…… 用记忆中残留的关键字进行检索
●…… 检索
●…… 通过问题票查找代码修改
4.5.2 Backlog 的例子
●…… 检索

4.6 回答“为什么要这样修改”的问题

4.7 本章总结

5 CI(持续集成)

5.1 CI(持续集成)

5.1.1 什么是 CI(持续集成)
●…… 集成(integration)
●…… 持续地进行集成就是 CI
5.1.2 使开发敏捷化
●…… 瀑布式开发的开发阶段
●…… 敏捷开发的开发阶段
5.1.3 为什么要进行 CI 这样的实践
●…… 成本效益
●…… 市场变化的速度
●…… 兼顾开发速度和质量
5.1.4 CI 的必要条件
●…… 版本管理系统
●…… build 工具
●…… 测试代码
●…… CI 工具
5.1.5 编写测试代码所需的框架
●…… 测试驱动开发(TDD)的框架
●…… 行为驱动开发(BDD)的框架
5.1.6 主要的 CI 工具
●…… Jenkins
●…… TravisCI

5.2 build 工具的使用方法

5.2.1 新建工程的情况
●…… 建立工程雏形
●…… 依赖关系的定义
●…… 执行测试
●…… 导入 Eclipse
5.2.2 为已有工程添加自动 build 功能
5.2.3 build 工具的总结

5.3 测试代码的写法

5.3.1 作为 CI 的对象的测试的种类
5.3.2 何时编写测试
●…… 新建工程的情况
●…… 已有工程中没有测试的情况
●…… 修改 bug 或添加新功能的情况
5.3.3 棘手的测试该如何写
●…… 和外部系统有交互的测试
●…… 使用 mocking 框架进行测试
●…… 使用内存数据库进行测试
●…… 数据库变更管理和配置文件管理的测试
●…… UI 相关的测试
●…… 棘手的测试要权衡工数

5.4 执行基于 Jenkins 的 CI

5.4.1 Jenkins 的安装
●…… 使用本地安装包进行安装
5.4.2 Jenkins 能干些什么
5.4.3 新建任务
5.4.4 下载代码
5.4.5 自动执行 build 和测试
●…… 定期执行
●…… 轮询版本管理系统
●…… build 的记述
5.4.6 统计结果并生成报表
5.4.7 统计覆盖率
●…… 覆盖率统计工具
●…… Maven Cobertura 插件的安装
●…… Jenkins 插件的配置
5.4.8 静态分析
5.4.9 配置通知

5.5 CI 的运用

5.5.1 build 失败了该怎么办
●…… Subversion 等中央集权型版本管理系统的情况
●…… Git 等分布式管理系统的情况
●…… 测试后合并
5.5.2 确保可追溯性
●…… 关联 build 和提交
●…… 关联缺陷管理

5.6 本章总结 借助 CI 能够实现的事情

6 部署的自动化(持续交付)

6.1 应该如何部署

6.1.1 部署自动化带来的好处
●…… 细粒度、频繁地发布可以使风险可控
●…… 能尽快地获得用户的反馈
●…… 团队的规模可控

6.2 部署的自动化

6.2.1 部署自动化方面的共识
6.2.2 部署流水线
●…… 通过自动化加快部署速度
●…… 任何人都能够实施部署是很重要的
6.2.3 服务提供工具链(provisioning tool chain)

6.3 引导(Bootstrapping)

6.3.1 Kickstart
●…… Kickstart 的使用方法
●…… 使用时的注意事项
●…… Kickstart 的配置示例
6.3.2 Vagrant
●…… 为每一位开发人员准备实体电脑比较困难
●…… 使用虚拟机时的注意事项
●…… 什么是 Vagrant
●…… Vagrant 的安装及运行方法

6.4 配置(Configuration)

6.4.1 不使用自动化时的问题
6.4.2 Chef
●…… Chef 的构成
●…… 目录构成和文件配置
●…… node.json
●…… setup.json
●…… solo.rb
●…… default.rb
●…… virtualhost.conf.erb
●…… Chef 的运行方法和运行结果
●…… 使用 Chef 的优点
●…… 使用 Chef 时的注意事项
●…… 使用 Chef 的时间点
6.4.3 serverspec
●…… 什么是 serverspec
●…… serverspec 的安装
●…… 测试文件的记述方式
●…… httpd_spec.rb
●…… git_spec.rb
●…… serverspec 的执行方法及执行结果
●…… serverspec 的优点
6.4.4 最佳实践(其1)
●…… Vagrantfile
●…… default.rb
6.4.5 最佳实践(其2)
6.4.6 实现物理服务器投入运营为止的所有步骤的自动化

6.5 编配(Orchestration)

6.5.1 发布作业的反面教材
6.5.2 Capistrano
●…… Capistrano 的系统构成
●…… Capistrano 的安装
●…… deploy.rb
●…… Capistrano 的执行方法
6.5.3 Fabric
●…… Fabric(串行执行)的情况
●…… Capistrano(并行执行)的情况
●…… 理解本地服务器和远程服务器操作上的区别
●…… Fabric 的运行方法
6.5.4 Jenkins
●…… 主节点(master node)和从节点(slave node)的协作
●…… 从节点的添加
●…… 任务的添加
●…… 任务的执行
6.5.5 最佳实践
●…… 结合 Jenkins 和 Fabric
6.5.6 考虑安全问题

6.6 考虑运用相关的问题

6.6.1 不中断服务的部署方法
6.6.2 蓝绿部署(blue-green deployment)
6.6.3 云(cloud)时代的蓝绿部署
6.6.4 回滚(rollback)相关问题的考察
●…… 随时准备好退路
●…… 数据库模式的版本管理
●…… 回滚的验证
●…… 只更新代码的发布时的回滚
●…… 数据库模式更新时的回滚

6.7 本章总结

7 回归测试

7.1 回归测试

7.1.1 什么是回归测试
7.1.2 测试分类的整理
●…… 支持团队的技术层面的测试(第1象限)
●…… 支持团队的业务层面的测试(第2象限)
●…… 评价产品的业务层面的测试(第3象限)
●…… 使用技术层面测试的产品评价(第4象限)
7.1.3 回归测试的必要性
●…… 退化(degrade)的发生
●…… 应该实现自动测试的原因
7.1.4 回归测试自动化的目标

7.2 Selenium

7.2.1 什么是 Selenium
7.2.2 Selenium 的优点
●…… 自动化测试用例制作简单
●…… 支持多种浏览器及 OS
7.2.3 Selenium 的组件
●…… Selenium IDE
●…… Selenium Remote Control(Selenium RC)
●…… Selenium WebDriver
7.2.4 测试用例的制作和执行
●…… Selemium IDE 的安装和运行
●…… Selenium 的测试用例
●…… 什么是好的测试用例
●…… 用 Selenium Server 来运行测试
7.2.5 Selenium 的实际应用
●…… 测试页面是否有改动
●…… 使 Selenium 测试稳定运行

7.3 Jenkins 和 Selenium 的协作

7.3.1 关联 Jenkins 和 Selenium 的步骤

7.4 Selenium 测试的高速化

7.4.1 利用 Jenkins 的分布式构建实现测试的并行执行
●…… Jenkins 的分布式构建的构成
●…… 分布式构建的配置
7.4.2 Selenium 测试并行化中的难点

7.5 多个应用程序版本的测试

7.5.1 应用的部署
7.5.2 从版本管理系统下载测试用例
7.5.3 用 Selenium 测试

7.6 本章总结

参考文献·网址

……全部

……Git、版本管理系统

……Scrum、敏捷开发

……build·测试

……持续集成

……持续交付

看完了

思维导图

高效团队开发:工具与方法

防止博客图床图片失效,防止图片源站外链:

http://www.processon.com/chart_image/5e5b3253e4b03627650b0fd9.png)

思维导图在线编辑链接:

https://www.processon.com/view/5e5b3253e4b03627650b0fd6

posted @ 2020-05-08 12:32  哀莫  阅读(349)  评论(0编辑  收藏  举报

欢迎访问我的主页!