这是我参与「第三届青训营 -后端场」笔记创作活动的的第7篇笔记.
从需求到上线全流程
为什么要有流程
1.1 团队规模和流程的关系
为什么要有流程
- 个人开发不需要流程
- 超过一个人的团队需要协作
- 团队规模的上升会出现很多问题
1.2 传统的瀑布模型
- 工作流程直观表达
- 定义了标准的研发阶段
- 流程为本，理想化模型
需求->开发->测试->发布->运维
1.3 敏捷开发
- 以小团队快速迭代
- 团队合作更加紧密
- 以人为本，和用户沟通
1.4 The Scaled Agile Framework
SAFe是一套管理体系
- 精益产品开发
- 敏捷软件开发
- 系统思考 由多个SCRUM组成
有哪些流程
2.1 需求阶段
不要浪费时间讨论不应该存在的问题
MVP（Mininum Viable Product）思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
四象限法
2.2 开发阶段
云原生的发展，深刻改变了后端开发的工作
云原生下的开发
- 传统虚拟机
- 物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
- 运维人员负责维护和交付虚拟机
- 每个虚拟机都需要安装相应的依赖环境
- 容器化
- 容器是在操作系统中虚拟出来的
- 通过cgroup，namespace，Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和依赖作为一个整体，打包成镜像交付
- 单体架构
- 多个模块共同组成一个服务，服务体量较大
- 模块之间直接调用，不需要RPC通信
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
- 微服务
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
团队的分支策略
代码规范、自测、文档
- 代码规范
- 养成良好的注释习惯
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要cv代码
- 正确使用IDE的重构功能，防止修改错误
- 自测
- 单元测试
- 功能环境测试
- 测试数据构造
- 文档
- 大型改造需要由技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
2.3 测试阶段
UI测试、系统测试、集成测试、单元测试
2.4 发布阶段
很重要的工具 F12的网络 可以查看发生问题的部位在前端还是在后端
发布过程中需要做的事情
- 发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
- 变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，相应上线过程中的警告
- 对于自己负责的改动，在小流量或者是浏览环境进行功能验证
- 执行发布计划中的其他操作，例如线上配置，数据处理
- 值班同学
- 发布过程中的监控和警告要特别关注，如果有异常需要立刻判断是否由于变更引起
- 如果有变更引起的警告或者用户反馈，需要及时终止发布
各种发布模式
- 蛮力发布
- 金丝雀发布
- 滚动发布
- 蓝绿发布
- 红黑发布
2.5 运维阶段
一些可能出现的问题
- 用户量增加引起流量洪峰（双11，12306抢票）
- 数据库表的数据量增长导致查询速度变慢
- 内存 进程泄露导致服务器资源不足
- 光缆被挖断
