这是我参与「第三届青训营-后端场」笔记创作活动的的第5篇笔记.

一、为什么要有流程

团队决策->多人协作->交付、测试、修复bug->控制版本与流量->处理线上问题和用户反馈

传统瀑布模型

定义标准的研发阶段，以流程为本，理想化，效率较低
需求->开发->测试->发布->运维

敏捷开发

小团队快速迭代，团队合作紧密，以人为本

SAFe管理框架

精益产品开发、敏捷软件开发、系统思考
现代的scrum：敏捷教练、产品负责人、敏捷团队、敏捷发布火车

二、有哪些流程

需求阶段

MVP 最小化可行产品思想：站在用户的角度思考，收集用户反馈，快速迭代
四象限法：按照重要和紧急度划分

开发阶段

云原生的发展，深刻改变了后端开发的工作
云原生化：本地IDE->线上，无需搭建环境

虚拟机->容器

传统虚拟机：物理主机中虚拟出多个虚拟机，每个有自己的操作系统和依赖环境，运维人员负责交付
容器化：在操作系统中虚拟，实现容器之间的隔离，应用和其依赖作为一个整体，打包为镜像交付

架构

单体架构：多个模块组成一个服务，体量大：模块直接直接调用；服务整体扩缩；多人开发一个仓库，需要充分集成测试。
微服务架构：各个功能在不同服务中；调用需要进行RPC通信；不同模块可以独立扩缩容量；每个服务的代码仓库仅由少部分人维护。

规范

代码规范：注释；定义常量；重复的逻辑封装调用，不要copy；使用IDE的重构功能，防止修改错误
自测：单元测试、功能环境测试、测试数据构造
文档：编写技术设计文档和方案，接口文档方便与前端沟通

测试阶段

测试金字塔：单元测试->集成测试->系统测试->UI测试
发现越早，修改成本越低

功能环境：模拟线上，环境之间可以相互隔离
集成环境：不同功能合并，不同版本间的功能合并
回归环境：自动化测试脚本

发布阶段

人员

发布负责人：按照计划执行发布；通知各个相关人员发布进展；观察状态，处理异常
变更服务RD：检查服务的日志、监控、告警；小流量或预览环境进行功能验证；线上配置和数据处理等
值班：关注监控告警是否由变更引起，及时中止发布

发布模式

蛮力发布

优点：
简单成本低
缺点：
发布过程中服务中断，影响用户
适用：
测试环境部署，小公司或非核心业务

金丝雀发布

优点：
简单，用少量用户验证
缺点：
发布过程中服务中断，发现不了随用户量增大才体现的问题
适用：
测试环境部署、小公司或非核心业务

滚动发布

通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
优点：
发布过程服务不中断，充分验证服务功能
缺点：
流程复杂，对系统要求高；发布速度慢；不能在新老版本不兼容的时候用
适用：
发布系统能力强，可以平滑切换流量；自动化程度高，可以自动滚动

蓝绿发布

服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务；再切换为蓝组，升级绿组。
优点：
发布速度快，流程简单
缺点：
需要有一半机器承担所有流量的能力；出问题会影响全部用户
适用：
服务器资源丰富；新老版本不能兼容，要一次升级

红黑发布

与蓝绿相似，但是发布时会动态扩容新的服务，不需要常备两组。
优点：
发布速度快，流程简单
缺点：
机器数量需要能扩容一倍；出问题会影响全部用户
适用：
服务器资源丰富；新老版本不能兼容，要一次升级

运维阶段

修复、定位、周知、止损

三、怎样执行流程

DevOps

特点：代码管理、自动化测试、持续集成、持续交付
缺点：效率竖井（等待时长很长，处理时长很短），沟通很慢

全流程自动化

通过效能平台串联各个阶段：
需求发起、研发流程、写代码、测试环境的自动化；自动化测试触发和报告分析；发布过程可观测
减少无价值的等待：
分析整个流程的耗时，计算有价值的时间，优化流程使其效率提高