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 技
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
