这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
本文是我在学习青训营课程《从需求到上线全流程》的过程中记的笔记
1.为什么要有流程
1.1 传统的瀑布模型
一个最直观的流程模型
graph TD
需求 --> 开发 --> 测试 --> 发布 --> 运维
- 工作流程的直观表达
- 定义了标准的研发阶段
- 以流程为本，理想化模型
1.2 敏捷开发
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本，和用户沟通
1.3 The Scaled Agile Framework（SAFe）简介
SAFe是一套管理框架 如果说敏捷开发是一个团队内部的协作方式，那么SAFe就是在企业中，多个敏捷团队之间怎样配合
- 精益产品开发
- 敏捷软件开发
- 系统思考
现代的Scrum
- 敏捷教练 Scrum Master
- 产品负责人 Product Owner
- 敏捷团队 Scrum Team
- 敏捷发布火车 Agile Release Train
2.有哪些流程
2.1 需求阶段
不要浪费时间讨论不应该存在的问题 MVP（minimum viable product，最小化可行产品）思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
如果我们要给用户造一辆车，我们不应该第一天给他一个轮子，第二天给两个轮子，第三天给他一个底盘，第四天才让他开上车
我们应该先给用户一个简单能用的产品，比如一个滑板车，一个自行车，根据用户的反馈我们再逐步把车的功能升级，最终变成用户想要的产品
2.2 开发阶段
2.2.1 云原生下的开发
- 传统虚拟机
- 物理主机虚拟出多个虚拟机，每个虚拟机拥有自己的os
- 运维负责维护和交付虚拟机
- 每个虚拟机中都要安装相应的依赖环境
- 容器化
- 容器是在os上虚拟出来的
- 通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个整体，打包成镜像交付
- 单体架构
- 多模块共同组成一个服务，体量较大
- 模块之间直接调用，不需要RPC
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
- 微服务架构
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 每个服务的代码仓库仅由少部分人维护
2.2.2 代码规范和自测文档
代码规范
- 良好的注释习惯
- 不要有意义不明的数字或字符串，可以用常量来定义
- 重复逻辑抽象成公共的方法
- 正确使用IDE的重构功能
自测
- 单元测试
- 功能环境测试
- 测试数据构造
文档
- 大型改造需要有技术设计文档
- 好的接口文档能更方便的和前端进行沟通
2.3 测试阶段
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离 集成环境
- 不同人开发的功能合并在一起测试
- 迭代发布的所有功能合并在一起测试 回归环境
- 确保新功能不会影响老功能
- 一般借助自动化测试脚本
2.4 发布阶段
各种发布模式
2.4.1 蛮力发布
简单粗暴，直接用新版本覆盖老版本
2.4.2 金丝雀发布
由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名
2.4.3 滚动发布
每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
2.4.4 蓝绿发布
把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级
2.4.5 红黑发布
类似蓝绿发布，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务
2.4.6 总结
- 没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
- 有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
