流程模型 - 敏捷开发
敏捷开发更像是一种思想：
- 开发宣言
个体互动 高于 流程和工具
工作软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划 - 特点
以小团队快速迭代
团队成员之间的合作更加紧密
以人为本，和用户沟通 - 此思想发展出来的方法之一：scrum
- 此思想发展出规模化框架：The Scaled Agile Framework(SAFe)
开发完整流程
-
需求阶段
- MVP(最小化可行产品)思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
- 四象限法
- MVP(最小化可行产品)思想
-
开发阶段 - 云原生下的开发：
(1)传统虚拟机 vs 容器化
传统虚拟机
- 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
- 运维人员负责维护和交付虚拟机
- 每个虚拟机中都要安装相应的依赖环境
容器化
- 容器是在操作系统中虚拟出来的
- 通过cgroup,namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个整体，打包成镜像交付
（2）单体架构 vs 微服务架构
单体架构
- 多个模块共同组成一个服务，服务体量较大
- 模块之间直接调用，不需要RPC通信
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
微服务架构
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信(当前在解决的网络通信耗费大的问题)
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
（3）开发环境 本地 vs 线上
开发环境
- 开发环境逐渐云原生化
- FaaS，PaaS等技术，让开发逐渐从本地IDE向线上转变
- 从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用
团队的分支策略
Git里就有创建分支、合并分支的团队合作开发仓库。
- 多个团队成员之间各自用什么分支开发？
- 修改之间有冲突怎么解决？
- 出了问题的代码如何回退到之前的版本？
- 测试阶段
（1）开发不是说就只是做开发工作，也要对写完的每一段代码进行测试，不能仅仅依赖测试人员。
“测试不是独立隔离的活动，它本身就是开发过程的一部分，质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。”————《Google软件测试之道》
（2）测试环境
- 功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
- 集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
- 回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
-
发布阶段
发布模式
- 蛮力发布：简单粗暴，直接用新版本覆盖老版本
- 金丝雀发布：现在一台机器上发布，用少量用户验证新版本功能（由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来）
- 滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
- 蓝绿发布：把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级
- 红黑发布：和蓝绿发布类似，但是发布时会动态扩容出一组新服务，而不需要常备两组服务
没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布 有强大发布系统和服务器资源不足的公司一般使用滚动发布和蓝绿发布
- 运维阶段
发生事故关键动作：止损 - 周知 - 定位 - 修复
优化流程（质量和效率兼顾）
技术的发展会带来质量和效率的同时提高；
将质量保障融入到流程，将流程自动化；
从需求到上线全流程自动化，同时提高质量和效率。
- DevOps解决方案
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
- 效率竖井
- 流程中实际产生价值的部分很短
- 大量的时间用在等待和传递上
- 人和人之间的沟通很慢
- 全流程自动化
- 通过效能平台串联各个阶段
- 需求发起研发流程的自动化
- 写代码，环境测试部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
- 减少无价值的等待
- 分析整个流程的耗时，计算真正产生价值的时间
- 不断优化流程，让有价值的流程时间占比上升
- 通过效能平台串联各个阶段
总结：后端不仅仅是开发角色，还有测试、发布、运维等，这是一个六边形战士阿！！
