不要阻塞开发人员,这是实现持续交付的本质理念
为每个团队指定构建负责人或者发布工程师:优化交付流水线,提升交付效率
项目状态应该对参与整个过程(包括构建、部署、测试和发布)的所有人都是可见的
做好风险管理
迭代增量式交付是有效风险管理的关键
手工测试环境、试运行环境和生产环境总是需要严格的访问控制
让风险识别成为每日立会的一部分
做好审计
手工测试环境、试运行环境和生产环境总是需要严格的访问控制:指定谁能够访问“特权”环境。
要求每次部署都要进行审计,以确切知道到底修改了哪些内容。
文档自动化、自文档
开发人员要把运维人员当做重要用户
切忌吞噬错误信息
使用运维团队熟悉的技术:开发人员最早负责创建部署脚本,后面移交给运维团队负责维护
把创建和维护基础设施需要的所有内容都进行版本控制
以自动化方式进行配置和部署!
像对待生产环境一样对待测试环境!
容器化技术实现不可变基础设施
各个环境的手工配置 -> 自动化配置
对所有内容进行版本控制
指定依赖库的确切版本,不要用快照或者模式匹配版本
配置文件与二进制文件分离
创建全面的自动化测试套件:单元测试、组件测试、验收测试,每一种测试的代码覆盖率都高于80%以上
每次修改都能运行一次自动化测试集合
分层测试
把创建和迁移数据库全部变成自动化过程,是部署流程的一个组成部分
让测试自己创建它们所需的状态,并确保每个测试都独立于其他测试
对数据库进行版本管理,使用DbDeploy这样的工具管理数据迁移过程的自动化。
在大多数据情况下,不要在测试中使用生产数据集的副本。?
数据库回滚和无停机发布
蓝绿部署
大多数修改应该是增加操作(比如向数据库中增加新表或字段),尽可能不修改已存在的结构
测试数据
测试的独立性、原子性
其他类型的测试,一定不要使用生产数据库的一个dump,除非有特殊情况
部署流水线中的数据管理
提交测试:快速运行,避免复杂的数据准备
验收测试:后续阶段可以复用
容量测试:为测试提供足够的输入数据,可以看做验收测试的重复利用
每次创建分支,都要认识到它带来的成本
频繁提交代码合并到主干
新功能隐藏:功能开关统一管理达到特性隐藏的目的(Togglz?)
增量开发:将所有的变更都变成一系列的增量式小修改,而且每次小的修改都是可发布的。
抽象模拟分支(无法使用增量开发):修缮者模式,使用门面模式隔离待改造代码。
使用组件,根据不同部分修改的频率对应用程序进行解耦。
确保自动化测试、构建部署脚本都能够在开发机上运行
本地自动化测试:预测试提交pretested commit/个人构建personal build/试飞构建preflight build【保证本地开发所有验证方式与流水线上的验证方式一致,提高开发人员在本地发现问题的能力】
提交前在本地运行所有的提交测试,等提交测试通过后再继续工作
在可控的环境上部署开发的应用程序
修复破坏应用程序的任意修改是最高优先级的任务,构建失败后不要提交新代码
检出最近成功的代码
修改代码
第一次个人构建
第二次个人构建:拉取主干代码集成后本地测试
提交代码到主干
提交构建
增量迭代开发
抽象模拟分支
特性隐藏
共享机器池
Git提交日志插入截图:Share Bucket+Google Drive
远程开发机器/Web IDE
依赖的服务
维护一个单独的环境,让开发环境接入
服务虚拟化工具来模拟依赖的服务,Mountbank、WireMock
语法检查、规范检查、单元测试:Maven/Gradle插件
持续集成前的必要工作
代码审查
统一并明确代码审查标准
统一并明确日志提交规范
传达团队的代码规则、质量基准
LGTM(Looks good to me)
代码入库前的设计时检查:在设计阶段进行代码审查
代码入库前门禁检查,需要考虑灵活性,提供绕过机制
代码入库后检查
工具辅助的线下异步审查:依赖于Gitlab、Gerrit、Code Climate Engines,一对一审查
面对面审查:架构问题、结对编程
代码增量审查/代码全量审查
团队审查:适合专项讨论
代码审查计入工作量和绩效考评
原子提交
提交日志规范
互相尊重
基于讨论
提高运行静态检查和测试的方便性、灵活性:Maven/Gradle插件
提供沙盒环境方便验证和测试
容器
小范围的增量构建和验证?
测试数据:直接使用生产环境、生产数据的导出并脱敏
实时检验工具:IDE实时检验、Liveload
流水线建设原则
测试尽量完整,保证产品质量->完备的测试机制
运行速度够快->尽早反馈、提高交付速度
使用的所有环境尽量和生产环境一致->复现问题
所有相关角色提供构建状态可视化:持续交付流水线大屏显示
存储构建结果报告
只要有环节失败,就停止整个流水线!
制品库是特殊的版本控制系统,不需要保存所有版本。
为部署流水线的每个阶段创建脚本:脚本是系统中的一等公民
增量式实现流水线:如果流程中有手工操作部分,就在流水线中为它创建一个占位符。
编译、单元测试、组装打包、代码分析
少于五分钟,一定不要超过十分钟
提交测试:单元测试、组件测试
只有在某个错误让提交阶段的其他任务无法执行时,才停下来否则就直至提交阶段全部运行完后,汇总所有的错误和失败报告
此阶段的结果:结果报告、二进制包、元数据
配置环境、部署二进制文件、冒烟测试、验收测试
令验收测试失败的构建版本不能被部署
先部署再测试,重用部署脚本。
类生产环境运行验收测试:大部分是功能验收测试,关注功能正确性
开发人员能够在自己的开发环境中运行自动化验收测试
测试的关注点在系统的行为,而非数据本身。所以抵制使用生产数据的备份做为验收测试
验收测试的性能不是主要考虑问题,重点在测试的全面性。
正确地做验收测试:不要幼稚地对照着验收测试条件,盲目地把所有东西都自动化。
验收测试可以看作所有后续测试阶段(包括容量测试)的某种模板:从部署准备开始,然后核实环境和应用程序都已被正确配置和部署,最后执行测试。
手工测试:探索性测试、易用性测试
非功能测试:性能、安全、可维护、可扩展
对不同环境采用同一部署方式:使用同样的脚本向所有环境部署,包括开发机器
一键式部署是对环境进行修改的唯一途径。
部署测试:对部署进行冒烟测试,验证部署是否成功,证明其部署的可靠性
确保部署流程是幂等的
只有通过了自动化构建、测试和部署的那些修改才能发布!
明确每个环境的部署和发布都是由谁负责
发布计划:第一次发布,产出一些文档、自动化脚本或其他形式的流程步骤
首次部署:首个迭代的主要目标之一就是在迭代结束时,让部署流水线的前几个阶段可以运行,实现部署流水线的“抽水泵”。
部署流水线的提交阶段。
一个用于部署的类生产环境。
通过一个自动化过程获取在提交阶段中生成的二进制包,并将其部署到这个类生产环境中。
一个简单的冒烟测试,用于验证本次部署是正确的,并且应用程序正在运行。
对发布过程进行建模并让构建晋级
为了达到发布质量,一个构建版本要通过哪些测试阶段
每个阶段需要设置什么样的晋级门槛或需要什么样的签字许可。
对于每个晋级门槛来说,谁有权批准让某个构建通过该阶段。
将每次已通过验收测试的变更版本部署在试运行环境中
紧急修复:紧急修复版本也要走完标准的部署流水线,与其他代码变更没什么区别。
结对做!
有时候回滚比部署新的修复版本更划算。
持续部署:每当有版本通过自动化测试之后,就将其部署到生产环境中。【需要依赖强大的自动化测试机制】
周期时间(cycle time),从决定要做某个特性开始,直到把这个特性交付给用户的这段时间
自动化测试覆盖率
代码库特征
缺陷数量
交付速度
提交版本库次数
构建次数
构建失败次数
构建所花时间
职能团队提供平台和工具,让全栈工程师能够自己处理端到端的工作,实现DevOps。
全栈开发:工程师不再只是对某一个单一职能负责,而是对最终产品负责。
制品与源代码版本管理:放置在制品包中的元数据,体现源代码版本号。
源代码与需求/Bug的版本关联:提交代码时需要在注释里注明需求ID、测试用例ID等。