从需求到上线全过程 | 青训营笔记

zia
169 阅读11分钟

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

01. 为什么要有流程

1.1 团队规模和流程关系

为什么要有流程？

  • 个人开发是不需要流程的
  • 超过一个人的团队就需要协作
  • 随着团队规模上升，会出现全新的问题

复杂项目的问题

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

1.2 传统的瀑布模型

image-20220523001812377.png

主要分为五个部分：

1、需求 2、开发 3、测试 4、发布 5、运维

传统的瀑布模型是以流程为本的理想化模型

1.3 敏捷开发

敏捷开发宣言的价值观如下

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

也就是说，尽管右项有其价值，我们更重视左项的价值

敏捷开发应该做到

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

1.4 SAFe简介

SAFe(The Scaled Agile Framework)是一套管理框架，这套框架是为企业中实施敏捷开发提供一套方法论，如果说敏捷开发是一个团队内部的协作方式子，那么SAFe就是在企业中，多个敏捷团队之间怎样配合

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

现在的Scrum

  • 敏捷教练
  • 产品负责人
  • 敏捷团队
  • 敏捷发布火车

现在软件开发的阵型像是特种部队，每个人都是身怀绝技，虽然大家会分工

但是并不是说产品设计只由产品经理负责，领导负责分配任务

大家的决策和配合都是非常有凝聚力的行动

如果一个scrum就是一个战术小队

敏捷教练就好比是小队的队长，产品负责人是负责联络指挥部和发布任务的人，其他团队成员就是特种兵

大家也不是按照一个方阵去前进，而是用更敏捷的方式去前进，也就说敏捷发布火车

1.5 团队的流程

image-20220523003701540.png

人员&名词解释

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

会议解释

  • 待办事项整理会议(Backlog Grooming Meeting)

    • 产品负责人描述下个选代希望实现的用户故事,PM提出需求列表

  • 迭代计划会议(Sprint Planning Meeting)

    • 选择选代的任务和估算工作量

  • 每日站会(Standup Meeting)

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

  • 评审会(Review Meeting)

    • 小组向产品负责人展示选代工作结果

  • 反思会(Retrospective Meeting)

    • 在每个选代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好

02. 有哪些流程

2.1 需求阶段

image-20220523004226778.png

说到需求阶段，马斯克在接受一个采访的时候讲过一个故事

他们在做特斯拉生产线的自动化的时候，有一个零件的安装自动化总是出问题

特斯拉的工程师为了优化这个自动化流程，投入了大量的资金和精力

后来马斯克问他们的技术人员，为什么需要这个零件，结果发现大家居然并不清楚

最后证明其实在电动车上，根本不需要这个零件 所以围绕着这个不应该存在的问题，进行了大量投入，造成了很多浪费

所以，这个故事就告诉我们一个道理，不要浪费时间讨论不应该存在的问题

MVP的思维方式

如果我们要给用户造一辆车，我们不应该第一天给他一个轮子，第二天给两个轮子，第三天给他一个底盘，第四天才让他开上车

我们应该先给用户一个简单能用的产品，比如一个滑板车，一个自行车，根据用户的反馈我们再逐步把车的功能升级，最终变成用户想要的产品

image-20220523004628182.png

2.2 开发阶段

云原生的发展，深刻改变了后端开发的工作

image-20220523004825113.png

云原生的开发阶段

部署形式转变

image-20220523005342664.png

  • 传统虚拟机

    • 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
    • 运维人员负责维护和交付虚拟机
    • 每个虚拟机中都要安装相应的依赖环境

  • 容器化

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

架构形式转变

image-20220523005942002.png

  • 单体架构

    • 多个模块共同组成一个服务，服务体量较大
    • 模块之间之间调用，不需要RPC通信
    • 服务整体扩缩容量
    • 多人开发一个代码仓库，需要充分集成测试

  • 微服务架构

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

开发过程

image-20220523005924692.png

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

团队的分支策略

image-20220523010207209.png

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

代码规范、自测和文档

代码规范

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

自测

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

文档

大型改造需要有技术设计文档，方案评审

好的接口文档能更方便的和前端进行沟通

2.3 测试阶段

测试种类

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

image-20220523095531291.png

越底层的测试粒度越细，就需要越多的数量去覆盖所有场景，越顶层的测试越能用少量的case覆盖大多数场景

但是有一个软件开发中的常识：越早发现的缺陷解决成本越低

因为85%的缺陷是在开发阶段引入的，而如果要在上线之后修复他们，话费的成本可能是一开始就解决他们的数百倍 所以我们还是要尽可能早的发现bug，进行充分的单元测试

环境种类

image-20220523100033057.png

  • 功能环境

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

  • 集成环境

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

  • 回归环境

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

2.4 发布阶段

发布过程中要做的事

  • 发布负责人

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

  • 变更服务的相关

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

  • 值班同学

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

各种发布模式

1、蛮力发布

简单粗暴，直接用新版本覆盖老版本

image-20220523100409367.png

  • 优点

    • 简单
    • 成本低

  • 缺点

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

  • 使用

    • 测试环境部署
    • 小公司或者非核心的业务服务
2、金丝雀发布

image-20220523100634040.png

  • 优点

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

  • 缺点

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

  • 使用

    • 测试环境部署
    • 小公司或者非核心业务
3、滚动发布

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

image-20220523100741945.png

  • 优点

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

  • 缺点

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

  • 适用

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

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

image-20220523100940627.png

  • 优点

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

  • 缺点

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

  • 适用

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

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

image-20220523101029380.png

  • 优点

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

  • 缺点

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

  • 适用

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

2.5 运维阶段

image-20220523101157613.png

当故障发生之后，我们是有几个关键的动作的：

首先是止损，尽快去让服务恢复功能

其次是要让服务的上下游感知到出了问题

当上面两个动作做了之后大家才需要去定位和修复问题

03. 流程怎样优化

3.1 怎样让生活更美好

image-20220523101456223.png

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

3.2 DevOps

image-20220523101552929.png

  • 代码管理
  • 自动化测试
  • 持续集成
  • 持续交付 image-20220523101629609.png

效率竖井

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

3.3 全流程自动化

image-20220523101717580.png

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

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

  • 减少无价值的等待

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

04. 总结

软件从需求到上线这个过程是一个逐渐成长的过程

一开始进入一家公司，我们肯定要学习公司的流程，团队成员分工，开发的节奏这些

背后其实是有理论依据的，就我们现代软件开发的几种模型

然后当我们真正成为了一个后端开发的角色，在需求到上线的各个阶段，我们需要去执行 需求评估，开发，测试，发布，运维

更进一步，当我们越来越有经验，甚至以后可能有些会承担团队的管理，那么就需要去思考怎样去优化这个流程，让大家的生活越来越美好

avatar
文章
阅读
粉丝