软件构成部分：可执行的代码、配置信息、运行环境、数据
- 不同环境下只进行一次编译
- 对环境的任何修改都应该作为配置信息管理，配置信息的更改都需要经过测试
- 如果运行环境需要修改，则修改后的环境也需要进行测试。环境包括：操作系统配置、应用程序依赖的软件集、网络配置及任何基础设置、外部系统
- 数据结构发生变化，同样需要经过测试
反馈流程：指完全以自动化的方式尽可能地测试每一次变更
- 创建可执行代码的流程
- 单元测试
- 质量检测：测试覆盖率以及其他与技术相关的度量项
- 功能测试验收
- 性能、有效性、安全性等非功能测试
- 探索性测试，给客户/最终应用演示
自动化测试反馈
【commit阶段】
- 运行速度快
- 尽可能全面，75%代码库覆盖率
- 环境中立，相对生产环境简单廉价
- 如果出现问题，绝不发布
【commit之后测试】 - 运行速度慢一些，适合并行执行
- 即使有些测试问题，也可以发布应用程序
- 运行环境尽可能与生产相同
不同版本、不同环境的配置放在版本控制中
- 开发人员都拥有自己的专属开发环境
- 无论部署在什么目标环境都应采用同一种部署方法
- 开发环境是特例，可以有多变性部署方法
软件的交付原则
- 为软件的发布创建一个可重复且可靠的过程
- 将几乎所有的事情自动化（构建、部署、测试、发布）
- 把所有的东西都纳入版本控制（需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、库文件、应用程序依赖的软件集、工具链及技术文档等)
- 找到流程中最痛苦的事情，并提交频繁地进行：如果集成最痛苦，那应在开始阶段就不断进行集成、测试；如果发布痛苦，每次提交并通过自动化测试后就进行发布
- 用户故事只有到了已发布才算完成，交付成果属于每个成员，交付前每个成员都为其负责
- 持续改进，交付过程中，整个团队召开回顾会议，提出改进方向及方法，每个改进点应该同一个人负责跟踪，确保改进被执行，下一次回顾会议，汇报结果。
