这是我参与「第三届青训营 -后端场」笔记创作活动的的第9篇笔记， 本次课主要讲了从需求到上线的全过程，包括为什么要有流程，有哪些流程和怎么执行流程

一、为什么要有流程

团队规模和流程的关系

• 个人开发者不需要流程
• 随着团队规模的上升，会出现新的问题

复杂项目的问题

• 需求阶段:每个人都有自己的想法,团队决策需要有一个过程
• 开发阶段:多人/多端协作开发,每个人有自己的安排,相互配合需要有一个流程
• 测试阶段:产物怎样交付,测试如何开展,BUG怎么修都需要流程و
• 发布阶段:怎样确保发布过程平稳丝滑,版本和流量如何控制,需要有规范
• 运维阶段:线上问题如何应急响应,处理用户反馈和线上问题需要有流程。

传统瀑布模型

• 非常注重流程的公司会使用

敏捷开发

更多的是一种思想，因为传统的流程太过复杂

敏捷开发

• 以小团队快速迭代
• 团队成员之间的合作更加紧密
• 以人为本,和用户沟通

团队流程示例

人员名词解释

• RD:研发
• PM:产品经理
• PRD:需求文档
• UED:用户体验设计
• QA:测试
• Scrum1:敏捷团队
• P0/P1:优先级0/优先级1
• Backlog: 规划列表

会议解释

• 待办事项整理会议(Backlog Grooming Meeting)产品负责人描述下个选代希望实现的用户故事,PM提出需求列表

• 迭代计划会议(Sprint Planning Meeting)选择选代的任务和估算工作量

• 每日站会(Standup Meeting)

  • 昨天你做了什么?
  • 今天你将要做什么?
  • 你有需要帮助的地方吗?

• 评审会(Review Meeting)小组向产品负责人展示选代工作结果
• 反思会(Retrospective Meeting)在每个选代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好

二、有哪些流程

需求阶段

• 不要浪费时间讨论不该存在的问题
• 日常阶段就应该砍一些需求
• MVP（最小化可行产品）思想：收集用户的反馈快速迭代

开发阶段

云原生下的开发

• 传统虚拟机

• 容器化

  • 容器是在操作系统中虚拟出来的
  • 通过cgroup, namespace和Union Mount等技术实现了容器之间的相互隔离,同时容器只有很低的开销
  • 应用和其依赖作为一个整体,打包成镜像交付

• 开发过程

  • 开发环境逐渐云原生化
  • FaaS, PaaS 等等技术,让开发逐渐从本地 IDE向线上转变从
  • 入职领到电脑搭建完一套完整的开发环境需要很久,通过WEB IDE等技术,环境未来将会开箱即用

团队的分支策略

• 多个团队成员之间各自用什么分支开发?
• 修改之间有冲突怎样解决?
• 出了问题的代码如何回退到之前版本?

代码规范

• 养成良好的注释习惯,超过三个月的代码,自己都会忘了当时在想什么
• 不要有魔法数字,魔法字符串
• 重复的逻辑抽象成公共的方法,不要copy代码
• 正确使用IDE的重构功能,防止修改错误

自测：

• 单元测试
• 功能环境测试
• 测试数据构造

测试阶段

测试种类

• 单元测试
• 集成测试
• 系统测试
• UI测试

环境种类

• 功能环境

• • 需要一个能模拟线上的环境进行开发和测试
  • 环境和环境之间能够隔离,不影响其他功能的开发和测试

• 集成环境

  • 不同人开发的功能合并在一起测试,相互之间的影响可能产生缺陷
  • 迭代发布的所有功能合并在一起测试,确保发布的所有功能之间的影响不产生缺陷

• 回归环境

  • 确保新的功能不对老的功能产生影响
  • 回归测试一般会借助自动化测试脚本

发布阶段

• 发布负责人

• • 负责按照计划执行发布
  • 需要通知各个相关人员发布进展
  • 观察各个服务的发布状态,及时处理异常

• 变更服务的相关

  • 按照上线checklist检查服务的日志,监控,响应上线过程中的告警
  • 对于自己负责的改动,在小流量或者是预览环境进行功能验证
  • 执行发布计划中的其他操作(如线上配置,数据处理等)

• 值班同学

  • 发布过程中的监控和告警需要特别关注,如果有异常需要立刻判断是否由变更引起
  • 如果有变更引起的告警或者用户反馈,需要及时中止发布

各种发布模式

蛮力发布：简单粗暴，直接用新版本覆盖老版本

• 优点

  • 简单

• 缺点

  • 出问题服务会中断
  • 影响全部用户

• 使用

  • 测试环境
  • 小公司或者非核心业务

金丝雀发布

• 优点

  • 简单
  • 用少量用户验证新版本功能

• 缺点

  • 出问题服务会中断
  • 发现不了随着用户增大才会暴露的问题

• 使用

  • 测试环境
  • 小公司或者非核心业务

滚动发布：实际中适用这个

• 优点

  • 发布过程中用户体验不会中断
  • 可以充分验证服务功能

• 缺点

  • 流程比较复杂，对发布系统又比较高的要求
  • 发布速度较慢
  • 新老版本不兼容的情况不能使用

• 适用

  • 发布系统能力较强，可以平滑切换流量
  • 发布自动化程度较高，可以自动滚动

蓝绿发布：把服务分成蓝绿两组,先把蓝组流量摘掉然后升级,只用绿组提供服务,之后切换全部流量,只用蓝组提供服务,然后升级绿组服务,最终两组全部升级。

• 优点

  • 发布速度快
  • 流程相对简单

• 缺点

  • 需要有一半机器承担所有流量的能力
  • 出问题会影响全部用户

• 适用

  • 服务器资源丰富
  • 新老版本不能兼容的情况,需要一次性升级到新版

红黑发布：和蓝绿发布类似,但是发布时会动态扩容出一组新的服务,而不需要常备两组服务。

• 优点

  • 发布速度快
  • 流程相对简单

• 缺点

  • 对机器数量仍然有要求，需要能扩容一倍
  • 出问题会影响全部用户

• 适用

  • 服务器资源丰富
  • 新老版本不能兼容的情况,需要一次性升级到新版

运维阶段

三、怎么执行流程

怎样让生活更美好

• 技术的发展会带来质量和效率的同时提高
• 将质量保障融入到流程,将流程自动化
• 从需求到上线全流程自动化,同时提高质量和效率

DevOps

• 代码管理
• 自动化测试
• 持续集成
• 持续交付

效率竖井

• 流程中实际产生价值的部分很短
• 大量时间在等待和传递上
• 人与人沟通很慢

全自动流程化

• 通过效能平台串联各个阶段

  • 需求发起研发流程的自动化
  • 写代码,测试环境部署的自动化
  • 自动化测试触发和报告分析
  • 发布过程可观测融入流程

• 减少无价值的等待

  • 分析整个流程的耗时,计算真正产生价值的时间
  • 不断优化流程,让有价值的流程时间占比上升