这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
Why：为什么要有流程
团队规模和流程的关系
- 个人开发者是不需要流程的
- 超过一个人的团队就需要协作
- 随着团队规模的提升，会出现新的问题
复杂项目没有流程会有什么问题：
- 需求阶段：每个人都有自己的想法，团队决策需要有一个过程
- 开发阶段：多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程
- 测试阶段：产物怎样交付，测试如何开展，BUG怎么修都需要流程
- 发布阶段：怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
- 运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程
瀑布模型
- 工作流程的直观表达
- 定义了标准的研发阶段
- 以流程为本，理想化模型
敏捷开发
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本，和用户沟通
规模化敏捷SAFe：The Scaled Agile Framework
SAFe 是一套管理框架，由多个scrum相互配合
- 精益产品开发
- 敏捷软件开发
- 系统思考
What：有哪些流程
需求阶段
- 不要浪费时间讨论不应该存在的问题
- 站在用户的角度思考
- 给出后端系统视角的建议，估算任务优先级
开发阶段
- 云原生下的开发：
- 容器化技术
- 微服务技术
- WebIDE
- 团队分支策略：
- 为什么会有分支策略
- 有哪些分支策略
- 合并的方式
- 代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止修改错误
- 自测
- 单元测试
- 功能环境测试
- 测试数据构造
- 文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
- 功能测试 功能测试，是为了测试一个新开发的功能，因此需要有能模拟线上的开发和测试环境，环境之间能相互隔离，这样可以独立验证不同的新功能
- 集成测试：集成测试，是为了把几个功能合在一起测试，因为可能各个新功能独立测试没有问题，但是合在一起却产生了bug
- 回归测试：回归测试是为了验证老的功能不被新的改动影响
发布阶段
- 各种发布模式
- 蛮力发布：简单粗暴，直接用新版本覆盖老版本。
- 金丝雀发布：由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。
- 滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
- 蓝绿发布：常备两个集群，先把流量全部切换到Group 1，升级Group2，然后再把流量全部切换到Group 2，升级Group 1。最终恢复流量。
- 红黑发布：与蓝绿发布类似，但是日常只有一个集群工作，发布时扩容一个集群升级新版本，切换流量后下掉老版本的集群。
- 发布过程要做的事
- 发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
- 变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作（如线上配置，数据处理等）
- 值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时中止发布
- 发布负责人
运维阶段
How：怎么样执行流程
- 效率竖井：
- 流程中实际产生价值的部分很短
- 大量的时间用在等待和传递上
- 人和人之间的沟通很慢
- DevOps解决方案
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
全流程自动化
- 通过效能平台串联各个阶段
- 需求发起研发流程的自动化
- 写代码，测试环境部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
- 减少无价值的等待
- 分析整个流程的耗时，计算真正产生价值的时间
- 不断优化流程，让有价值的流程时间占比上升
