Please enable JavaScript.
Coggle requires JavaScript to display documents.
持续交付
持续交付
第7章：提交阶段
流程
静态检查
代码分析
组装打包
单元测试
编译
构建代码也需要像开发代码一样维护
构建环境与脚本分离
重构
模块化
全体开发人员
也需要对构建系统有所有权（不要依赖构建专家）
团队成员
轮流担任
构建责任人（每周）
提供快速有用的反馈
纪律：
一旦提交阶段失败，团队就必须立即停下手上的工作，把它修复。
否则持续集成会渐渐失去意义。
把提交阶段分解为一系列的任务，只有某个错误让其他阶段的任务无法执行时，我们才会让提交阶段停止。否则直至提交阶段全部运行完毕后，才汇总所有的错误和失败报告，
以便可以一次性修复它们
原则与实践
单元测试
快
覆盖率80%
打桩，不要与第三方系统交互
强烈推荐使用模拟技术
避免使用数据库
避免异步
用户界面测试
尽可能
避免
用户界面测试
使用验收测试替代
时间：
少于5分钟，不会超过10分钟
二进制重用
：构建生成的二进制文件保存下来，供后续使用
第八章：自动化验收测试
流程
配置环境
部署二进制文件
冒烟测试
验收测试
测试替身对象
最小化外部依赖
如果与真正的外部系统集成，环境可能不可控
设计外部系统的适配层（
特别是第三方系统API
）
:red_cross: 常见的误解：验收测试一定要使用真正的外部系统
行为驱动测试
自动化验收用例
可执行的规格说明
原子化测试
并发测试
利用程序自身功能来隔离测试范围
应用程序驱动层
不要直接对UI做测试
提取dsl进行测试
:warning: 需要更多实践，当前经验不多
针对业务功能：满足用户所需
第9章：非功能需求的测试
作用
重现生产环境上的复杂缺陷
探测并调试内存泄漏
持久性测试
评估GC影响
GC调优
应用程序参数调优
第三方应用程序配置调优
模拟非正常，最糟糕场景
评估一些复杂问题的不同解决方案
模拟集成失败的情况
度量系统在不同硬件下的可扩展性
与外部系统进行交互的负载测试
复杂部署的回滚演练
有选择地使系统部分或者全部瘫痪，从而评估服务的优雅降级
策略
决定一种架构，特别注意网络和IO
了解和使用正确的模式（Release It）
不要为容量做无谓优化，鼓励写清晰简单的代码，没有明确测试结果表明有问题时，不能在代码可读性上让步
注意数据结构和算法复杂度的选择
处理线程时要特别小心
创建一些自动化测试来断言容量级别
使用调测工具关注测试中发现的性能问题，并修复
只要有可能，使用真实的生产环境容量来进行度量
分类
容量
吞吐量
性能
第10 章
创建发布策略
描述在测试和生产环境中应该遵循的流程，比如提交一个变更申请，以及申请授权
枚举所有环境，包括验收测试、容量测试、集成测试、用户验收测试环境，以及每个构建在这些环境的移动过程
每个环境部署和发布时谁负责
明确责任人
创建一个资产和管理配置策略
Amazon EC2
物理机
云平台PaaS
部署时使用的技术
ansible
puppet
chef
实现部署流水线的计划
对应用程序的监控需求，包括用于通知运维团队程序状态的API或者服务
讨论部署时和运行时的配置方法如何管理，已经与自动化部署流程是如何关联在一起的
比如tomcat配置文件
应用程序如何与外部系统集成
在哪个阶段集成
如何对外部集成做测试
一旦出现问题，如何与供应商沟通
如何记录日志详情，以便运维人员定位
指定灾难恢复计划，以便在灾难发生后，可以恢复应用程序状态
对软件的服务级别达成一致，比如高可用
生产环境的数量大小以及容量计划
会创建多少数据？
需要多少个日志或者数据库？
需要多少带宽或者磁盘空间？
客户对响应延迟的容忍？
如何对生产环境进行首次部署
如何修复生产环境的缺陷，对其打补丁
如何升级生产环境的应用程序和数据迁移
如何做应用程序的生产服务和技术支持
第一次发布
第一次部署应用程序所需步骤
如何对服务进行冒烟测试
如果部署出现问题，需要哪些步骤来撤销部署
对应用程序状态进行备份和恢复的步骤
日志文件地址，以及它包括什么样的信息描述
如果部署失败，重新进行部署的步骤
如何对应用程序进行监控
必要数据的迁移步骤
第11章：基础设施和环境管理