这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记。
流程
团队规模和流程的关系
随着团队规模的上升，需要协作，就需要流程。
如果复杂项目没有流程：
- 需求阶段：每个人都有自己的想法，团队决策需要有一个过程。
- 开发阶段：多人协作开发，每个人有自己的安排，相互配合需要有一个流程。
- 测试阶段：产品怎么交付，测试如何开展，BUG怎么修需要流程。
- 发布阶段：如何保证发布过程平稳丝滑，版本和流量如何控制，需要有规范
- 运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程。
传统的瀑布模型
流程排成一条线
需求->开发->测试->发布->运维
敏捷开发
- 小团队快速迭代
- 以人为本，和用户沟通
The Scaled Agile Framework(SAFe)
管理框架
由多个scrum相互配合
现代的Scrum
- 敏捷教练 Scrum Master
- 产品负责人 Product Owner
- 敏捷团队 Scrum Team
- 敏捷发布火车 Agile Release Train
字节团队的流程
名词解释
- RD：研发
- PM：产品经理
- PRD：需求文档
- UED：用户体验设计
- QA：测试
- Scrum1：敏捷团队1
- P0/P1：优先级0/优先级1
- Backlog：规划列表
会议解释
-
待办事项整理会议（Backlog Grooming Meeting），产品负责人描述下个迭代希望实现的用户故事，PM提出需求列表
-
迭代计划会议（Sprint Planning Meeting）选择迭代的任务和估算工作量
-
每日站会（Standup Meeting）
- 昨天你做了什么？
- 今天你将需要做什么？
- 你有需要帮助的地方吗？
- 评审会（Review Meeting）小组向产品负责人展示迭代工作结果
- 反思会（Retrospective Meeting）在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好
有哪些流程
需求阶段
不要浪费时间讨论不应该存在的问题。
MVP(minimum viable product 最小化可行产品)思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
开发阶段
云原生，改变了后端开发的工作。
传统虚拟机
- 物理主机上多个虚拟机，每个虚拟机有自己的操作系统
- 运维人员维护和交付虚拟机
- 每个虚拟机中都要安装相应的依赖
容器化
- 容器是在操作系统中虚拟出来的
- 容器之间相互隔离，容器开销低
- 应用和依赖作为一个整体，打包成镜像交付
单体架构
- 多个模块组成一个服务，服务体量较大
- 模块之间直接调用，不需要RPC
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
微服务架构
- 各个功能在不同的服务中
- 不同模块需要RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
WEB IDE开箱即用的环境
团队的分支策略
- 多个团队成员之间各自用什么分支开发？
- 修改之间有冲突怎样解决？
- 出了问题的代码如何回退到之前版本？
代码规范、自测和文档
- 注释习惯
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法
- 正确使用IDE的重构功能
- 单元测试
- 功能环境测试
- 测试数据构造
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
Google软件测试之道
在写完每一段代码之后立刻测试这段代码。
越早发现缺陷修复的成本越低
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境与环境之间能够隔离，不影响其他功能的开发和测试
集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
发布阶段
通过开发者工具调查问题
发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理日常
变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作（如线上配置，数据处理等）
值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时终止发布
发布模式
蛮力发布
优点
- 简单 成本低
缺点
- 发布过程中服务会中断
- 出了问题会影响全部用户
适用
- 测试环境部署
- 小公司或者非核心的业务服务
金丝雀发布
先发布一台机器，成功再全部发布
优点
- 相对简单
- 能够用少量用户验证新版本功能
缺点
- 发布过程中服务会中断
- 发现不了随用户量增大才会暴露的问题
适用
- 测试环境部署
- 小公司或者非核心的业务服务
滚动发布
每台服务都金丝雀发布
最常用
优点
- 发布过程中用户体验不会中断
- 可以充分验证服务功能
缺点
- 流程较复杂，对发布系统有比较高的要求
- 发布速度较慢
- 新老版本不兼容的情况不能使用
适用
- 发布系统能力较强，可以平滑切换流量
- 发布自动化程度高，可以自动滚动
蓝绿发布
服务分两组，升级时只用另一半服务，分别升级
优点
- 发布速度快，流程相对简单
缺点
- 需要有一半机器承担所有流量的能力
- 出问题会影响全部用户
适用
- 服务器资源丰富
- 新老版本不能兼容的情况，需要一次性升级到新版
红黑发布
不需要常备两组服务，发布时扩容一倍的服务。
优点
- 发布速度快，流程相对简单
缺点
- 对机器数量仍然有要求，需要能扩容一倍
- 出问题会影响全部用户
适用
- 服务器资源丰富
- 新老版本不能兼容的情况，需要一次性升级到新版
运维阶段
用户增加
数据量增加
服务资源不足
光缆被挖断
首先要止损。
流程怎么优化
流程自动化，同时提高质量和效率
DevOps
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
效率竖井
- 流程中实际产生价值的部分很短
- 大量时间用在等待和传递上
- 人和人之间的沟通很慢
全流程自动化
让有价值流程时间占比上升
后端的一周
周一
- 针对上个迭代开发的功能进行演示
- 反思上个迭代的不足
PM和UED已经准备好了明天要规划的需求列表
周二
Grooming会议
- 之前的一周，backlog里积累了92个需求
- 会议上，PO和PM阐述各个需求的价值
- Scrum Master和架构师确认需求包含的技术任务
- 总之，会议确认要做70个需求，并给你安排了10个需求。
周三
提交火车发布车票
- 之前开发的需求需要上线，提交一个发布车票
- 对其他人提交的上线工单进行Code review
- 修复代码缺陷
周四
- 之前提交车票的部分功能要在今天发布
- 发布过程中发现监控出现异常，终止发布，定位问题原因
- 发现自己代码有问题，需要进行回滚和修复
周五
Planning会议
- 发现下个迭代只能完成8个需求，按照优先级把2个需求移除迭代
- 将8个需求的工作量进行评估
- 把8个需求各自的开发和上线时间进行排期
