从需求到上线全流程笔记｜ 青训营笔记

这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记

1、流程

传统的瀑布模型

• 工作流程的直观表达

• 定义了标准的研发阶段

• 以流程为本，理想化模型

• 低效

  需求->开发->测试->发布->运维

敏捷开发

• 瀑布模型过于重视流程本身，无法适应市场变化

• 价值观

  • 个体和互动 > 流程和工具
  • 工作的软件 > 文档
  • 客户合作 > 合同谈判
  • 响应变化 > 遵循计划

• 特点

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

SAFe

• 精益产品开发

• 敏捷软件开发

• 系统思考

• 由多个团队相互配合

  • 敏捷教练-leader
  • 产品负责人-产品方向，与客户沟通
  • 敏捷团队
  • 敏捷发布火车

2、有哪些流程

需求阶段

不要浪费时间讨论不应该存在的问题

mvp思想

• 站在用户的角度思考
• 开发原型，收集用户反馈，快速迭代
• 考虑事情重要、紧急程度

开发阶段

• 云原生

  • 共享同一个os

  • 通过技术实现容器之间相互隔离，同时容器只有很低的开销

  • 微服务架构

    • 各个功能在不同的服务中
    • 不同的模块通过RPC通信
    • 不同模块可以独立扩缩容
    • 每个服务的代码仓库仅由少部分人维护

  • webIDE，开发逐渐从本地IDE向线上转变

• 分支策略

• 代码规范

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

• 自测

  • 单元测试

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

  • 功能环境测试

  • 测试数据构造

测试阶段

• 功能测试

功能测试，是为了测试一个新开发的功能，因此需要有能模拟线上的开发和测试环境，环境之间能相互隔离，这样可以独立验证不同的新功能

• 集成测试：集成测试，是为了把几个功能合在一起测试，因为可能各个新功能独立测试没有问题，但是合在一起却产生了bug
• 回归测试：回归测试是为了验证老的功能不被新的改动影响

发布阶段

• 发布负责人

  • 负责按照计划执行发布
  • 通知发布进展
  • 观察发布状态、及时处理异常

• 变更服务的相关rd

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

• 值班

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

• 发布模式

  • 蛮力发布：直接发布
  • 金丝雀发布：发布一台机器
  • 滚动发布：通过金丝雀方式逐步放大流量
  • 蓝绿发布：两个集群，流量切到一个集群升级另一个集群
  • 红黑发布 ：只有一个集群工作，发布时扩容一个集群升级新版本、切换后下掉老版本

运维阶段

• 止损
• 周知
• 定位
• 修复

3、执行流程

将质量保障融入到流程，自动化

DevOps

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

效率竖井

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

全流程自动化

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

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

• 减少无价值的等待

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

\