持续交付 发布可靠软件的系统方法（英文版）

图书标准信息

• 作者 [英]亨布尔（Humble）
• 出版社 人民邮电出版社
• 出版时间 2015-10
• 版次 1
• ISBN 9787115403759
• 定价 89.00元
• 装帧 平装
• 开本 16开
• 纸张 胶版纸
• 页数 444页
• 字数 646千字

【内容简介】

本书讲述如何实现更快、更可靠、低成本的自动化软件交付，描述了如何通过增加反馈，并改进开发人员、测试人员、运维人员和项目经理之间的协作来达到这个目标。本书由三部分组成：部分阐述了持续交付背后的一些原则，以及支持这些原则的实践；二部分是本书的核心，全面讲述了部署流水线；第三部分围绕部署流水线的投入产出讨论了更多细节，包括增量开发技术、高级版本控制模式，以及基础设施、环境和数据的管理和组织治理。
  本书适合所有开发人员、测试人员、运维人员和项目经理学习参考。

【作者简介】

Jez Humble ThoughtWorks公司首席咨询顾问，致力于帮助企业快速、可靠地交付高质量软件，经常在各种敏捷技术大会上发表演讲，拥有牛津大学物理学学士学位和伦敦大学民族音乐学硕士学位。2000年至今，他曾在各行业和不同技术领域担任系统管理员、开发人员、培训人员、咨询师和经理人员。

David Farley 具有20多年的大型分布式系统开发经验，是采用敏捷开发技术的先行者，曾作为技术负责人参加了ThoughtWorks公司许多极具挑战性的软件项目。目前帮助构建伦敦多项金融衍生品交易所（London Multi-Asset Exchange，LMAE）。

【目录】

目录

Part I: Foundations / 基础篇1

Chapter 1: The Problem of Delivering Software / 软件交付的问题3

Introduction / 引言3

Some Common Release Antipatterns / 一些常见的发布反模式4

Antipattern: Deploying Software Manually / 反模式：手工部署软件5

Antipattern:Deploying to a Production-like Environment Only after Development Is Complete / 反模式：开发完成之后才向类生产环境部署7

Antipattern: Manual Configuration Management of  Production Environments / 反模式：生产环境的手工配置管理9

Can We Do Better? / 我们能做得更好吗10

How Do We Achieve Our Goal? / 如何实现目标11

Every Change Should Trigger the Feedback Process  / 每次修改都应该触发反馈流程13

The Feedback Must Be Received as Soon as Possible  / 　必须尽快接收反馈/ 14

The Delivery Team Must Receive Feedback and Then Act on It  / 交付团队必须接收反馈并作出反应15

Does This Process Scale? / 这个流程可以推广吗16

What Are the Benefits? / 收效17

Empowering Teams / 授权团队17

Reducing Errors / 减少错误18

Lowering Stress / 缓解压力20

Deployment Flexibility / 部署的灵活性21

Practice Makes Perfect / 多加练习，使其完美22

The Release Candidate / 候选发布版本22

Every Check-in Leads to a Potential Release23

Principles of Software Delivery / 软件交付的原则24

Create a Repeatable,Reliable Process for Releasing Software / 为软件的发布创建一个可重复且可靠的过程24

Automate Almost Everything / 将几乎所有事情自动化25

Keep Everything in Version Control / 把所有的东西都纳入版本控制26

If It Hurts, Do It More Frequently, and Bring the Pain Forward / 提前并频繁地做让你感到痛苦的事26

Build Quality In / 内建质量27

Done Means Released / “DONE”意味着“已发布”27

Everybody Is Responsible for the Delivery Process / 交付过程是每个成员的责任28

Continuous Improvement / 持续改进28

Summary / 小结29

Chapter 2: Configuration Management / 配置管理31

Introduction / 引言31

Using Version Control / 使用版本控制32

Keep Absolutely Everything in Version Control / 对所有内容进行版本控制33

Check In Regularly to Trunk / 频繁提交代码到主干35

Use Meaningful Commit Messages / 使用意义明显的提交注释37

Managing Dependencies / 依赖管理38

Managing External Libraries / 外部库文件管理38

Managing Components / 组件管理39

Managing Software Configuration / 软件配置管理39

Configuration and Flexibility / 配置与灵活性40

Types of Configuration / 配置的分类41

Managing Application Configuration / 应用程序的配置管理43

Managing Configuration across Applications / 跨应用的配置管理47

Principles of Managing Application Configuration / 管理配置信息的原则47

Managing Your Environments / 环境管理49

Tools to Manage Environments / 环境管理的工具53

Managing the Change Process / 变更过程管理53

Summary / 小结54

Chapter 3: Continuous Integration / 持续集成55

Introduction / 引言55

Implementing Continuous Integration / 实现持续集成56

What You Need Before You Start / 准备工作56

A Basic Continuous Integration System / 一个基本的持续集成系统57

Prerequisites for Continuous Integration / 持续集成的前提条件59

Check In Regularly / 频繁提交59

Create a Comprehensive Automated Test Suite / 创建全面的自动化测试套件60

Keep the Build and Test Process Short / 保持较短的构建和测试过程60

Managing Your Development Workspace / 管理开发工作区62

Using Continuous Integration Software / 使用持续集成软件63

Basic Operation / 基本操作63

Bells and Whistles / 铃声和口哨63

Essential Practices / 必不可少的实践66

Don’t Check In on a Broken Build / 构建失败之后不要提交新代码66

Always Run All Commit Tests Locally before Committing, or Get Your CI Server to Do It for You / 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事66

Wait for Commit Tests to Pass before Moving On / 等提交测试通过后再继续工作67

Never Go Home on a Broken Build / 回家之前，构建必须处于成功状态68

Always Be Prepared to Revert to the Previous Revision / 时刻准备着回滚到前一个版本69

Time-Box Fixing before Reverting / 在回滚之前要规定一个修复时间70

Don’t Comment Out Failing Tests / 不要将失败的测试注释掉70

Take Responsibility for All Breakages That Result from Your Changes  /为自己导致的问题负责 70

Test-Driven Development / 测试驱动的开发71

Suggested Practices / 推荐的实践71

Extreme Programming (XP) Development Practices / 极限编程开发实践71

Failing a Build for Architectural Breaches  / 若违背架构原则，就让构建失败72

Failing the Build for Slow Tests / 若测试运行变慢，就让构建失败73

Failing the Build for Warnings and Code Style Breaches / 若有编译警告或代码风格问题，就让测试失败 73

Distributed Teams / 分布式团队75

The Impact on Process / 对流程的影响75

Centralized Continuous Integration / 集中式持续集成76

Technical Issues /技