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

一、为什么要有流程

1.1 团队规模和流程的关系

个人开发者是不需要流程的
超过一个人的团队就需要协作
随着团队规模上升，会出现全新的问题

复杂项目没有流程会有什么问题：
需求阶段：每个人都有自己的想法，团队决策需要有一个过程
开发阶段：多人/多端协作开发，每个人都有自己的安排，相互配合需要有一个流程
测试阶段：产物怎样交付，测试如何开展，BUG怎么修需要流程
发布阶段：怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程

1.2 传统的模型

工作流程的直观表达
定义了标准的研发阶段
以流程为本，理想化模型

1.3 敏捷开发

更多是一种思想
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

以小团队快速迭代
团队成员之间的合作更加紧密
以人为本，和用户沟通

1.4 The Scale Agile Framework简介

SAFe是一套管理框架
精益产品开发
敏捷软件开发
系统思考

二、有哪些流程

2.1 需求阶段

不要浪费时间讨论不应该存在的问题

MVP（最小化可行产品)思想
站在用户的角度考虑
收集用户反馈，快速迭代

2.2 开发阶段-云原生下的开发

传统虚拟机
在物理主机中虚拟出多个虚拟机，每个人虚拟机拥有自己的操作系统
运维人员负责维护和交付虚拟机
每个虚拟机中都要安装相应的依赖环境

容器化
容器是在操作系统中虚拟出来的
通过cgroup,nemespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
应用和其依赖作为一个整体，打包成镜像交付

单体架构
多个模块共同组成一个服务，服务体量较大
模块之间直接调用，不需要RPC通信
服务整体扩缩容量
多人开发一个代码仓库，需要充分集成测试

微服务架构
各个功能在不同的服务中 不同模块需要进行RPC通信
不同模块可以独立扩缩容
每个服务的代码仓库仅由少部分人维护

代码规范
养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
不要有魔法数字，魔法字符串
重复的逻辑抽象成公共的方法，不要copy代码
正确使用IDE的重构功能，防止修改错误

自测
单元测试
功能环境测试
测试数据构造

文档
大型改造需要有技术设计文档，方案评审
好的接口文档能更方便和前端进行沟通

2.3 测试阶段

测试金字塔：
UI测试
系统测试
集成测试
单元测试

功能环境
需要一个能墨迹线上的环境进行开发和测试
环境和环境之间能够隔离，不影响其他功能的开发和测试

集成环境
不同人开发的功能合并在一起测试，互相之间的影响可能产生缺陷
迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷

回归环境
确保新的功能不对老的功能产生影响
回归测试一般会借助自动化测试脚本

2.4 发布阶段

发布负责人
负责按照计划执行发布
需要通知各个相关人员发布进展
观察各个服务的发布状态，及时处理异常

表更服务的相关RO
按照上线checklist检查辅助的日志，监控，响应上线过程中的告警
对于自己负责的改动，在小流量或者预览环境进行功能验证 执行发布计划中的其他操作（如线上配置，数据处理等）

值班同学
发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起 如果由变更引起的告警或者用户反馈，需要及时中止发布

蛮力发布
简单粗暴，直接用新版本覆盖老版本

金丝雀发布 由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名

滚动发布
每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑

蓝绿发布
把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级

2.5 运维阶段

飞机平飞阶段也有可能发生事故

三、怎样执行流程

3.1 怎样让生活更美好

技术的发展会带来质量和效率的同时提高

3.2 DevOps

形成一个闭环

3.3 全流程自动化

通过效能平台串联各个阶段
需求发起研发流程的自动化
写代码，测试环境部署的自动化
自动化测试触发和报告分析 发布过程可观测融入流程

减少无价值的等待
分析整个流程的耗时，计算真正产生价值的时间
不断优化流程，让有价值的流程时间占比上升