从需求到上线全流程

Why - 为什么需要有流程

• 随着团队规模和问题复杂度的上升，一个人搞定一切就不可能了，超过了一个人，就需要进行团队协作，自然也就需要有流程。

• 瀑布模型：

  • 按照时间节点参与会议，产出文档（系统分析，概要设计，详细设计，接口文档，提测文档等）

  • 按照时间节点交付测试

  • 按照时间节点发布

    • 工作流程比较直观
    • 定义标准的研发阶段
    • 以流程为本，理想化模型

• 敏捷开发：

  • 跟随迭代制定规划，进行开发

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

• The Scaled Agile Framework (SAFe) 简介

  • 精益产品开发
  • 敏捷软件开发
  • 系统思考

WHAT - 有哪些流程

需求阶段：

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

• 站在用户的角度思考（提出一些需要的需求、删除不需要的需求）

可能说用户需要先看到东西，再逐步去优化

开发阶段：

• 云原生下的开发：

  • 容器化技术

  • 微服务技术

  • WebIDE

• 团队分支策略：

  • 为什么会有分支策略：重点去掌握
  • 有哪些分支策略：
  • 合并的方式：

• 代码规范：

  • 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
  • 不要有魔法数字，魔法字符串(就是直接在代码中出现数字， 尽量定义为常量)
  • 同样的逻辑抽象成公共的办法，不要去copy代码
  • 正确的使用IDE重构功能，放置修改

测试阶段：

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

• 集成测试：集成测试，是为了把几个功能合在一起测试，因为可能各个新功能独立测试没有问题，但是合在一起却产生了bug

• 回归测试：回归测试是为了验证老的功能不被新的改动影响（一般会借助自动化脚本测试）

发布阶段：

发布过程要做的事

• 发布负责人

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

• 变更服务的相关RD

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

• 值班同学

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

各种发布模式

• 蛮力发布：简单粗暴，直接用新版本覆盖老版本。 ---- （全量发布会导致暂停业务）

• 金丝雀发布：（先开启一台机器看看有没有问题，再逐步开启多台机器） ---- （全量发布会导致暂停业务）

• 滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑

• 蓝绿发布：常备两个集群，先把流量全部切换到Group 1，升级Group2，然后再把流量全部切换到Group 2，升级Group 1。最终恢复流量。

• 红黑发布：与蓝绿发布类似，但是日常只有一个集群工作，发布时扩容一个集群升级新版本，切换流量后下掉老版本的集群

运维阶段：

How

全流程自动化

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

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

• 减少无价值的等待

  • 分析整个流程的耗时，计算真正产生价值的时间

-   不断优化流程，让有价值的流程时间占比上升