【软件开发】从需求到上线

KiraFenvy
420 阅读8分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第23天，点击查看活动详情

为什么有流程

团队与流程的关系

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

瀑布模型

以流程为本，理想化模型，严格遵守 需求->开发->测试->发布->运维

敏捷开发

敏捷宣言：

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

scrum方法，5个流程分布到每一次迭代

1.4 The Scaled Agile Framework (SAFe)规模化开发

如果说敏捷开发是一个团队内部的协作方式，那么SAFe就是在企业中，多个敏捷团队（scrum）之间怎样配合

SAFe是一套管理框架

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

现代的 Scrum：

  • 敏捷教练 Scrum Master
  • 产品负责人Product Owner 与客户沟通，发布迭代任务
  • 敏捷团队 Scrum Team
    = 敏捷发布火车 Agile Release Train

实例

  • 瀑布模式

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

  • 敏捷团队

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

    • 参与待办事项整理会议（Backlog Grooming Meeting）

      • PO描述下个迭代希望实现的用户故事

    • 迭代计划会议（Sprint Planning Meeting）

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

    • 每日站会（Standup Meeting）

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

    • 评审会（Retrospective Meeting）

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

    • 反思会（Retrospective Meeting）

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

流程

需求阶段

MVP (minimum viable product，最小化可行产品)思想

  • 不要浪费时间讨论不应该存在的问题
  • 站在用户的角度思考
  • 给出后端系统视角的建议，估算任务优先级

四象限分配时间：

image.png

开发阶段

云原生下开发

传统虚拟机

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

容器化：

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

单体架构

  • 多个模块共同组成一个服务，服务体量较大
  • 模块之间直接调用，不需要RPC通信
  • 服务整体扩缩容量
  • 多人开发一个代码仓库，需要充分集成测试 微服务架构
  • 各个功能在不同的服务中
  • 不同模块需要进行RPC通信
  • 不同模块可以独立扩缩容
  • 每个服务的代码仓库仅由少部分人维护

开发环境的云原生化（Faas、Paas、甚至web IDE）

团队的分支策略

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

2.4 代码规范、自测和文档

代码规范

  • √养成良好的注释习惯
  • √不要有魔法数字，魔法字符串
  • √重复的逻辑抽象成公共的方法，不要copy代码
  • √正确使用IDE的重构功能，防止修改错误

自测

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

文档

  • √大型改造需要有技术设计文档，方案评审
  • √好的接口文档能更方便的和前端进行沟通

测试阶段

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

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

  • 回归测试：回归测试是为了验证老的功能不被新的改动影响

发布阶段

  • 发布负责人

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

  • 变更服务的相关RD

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

  • 值班同学

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


作者：青训营官方账号
链接：juejin.cn/post/709712… 来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

蛮力发布

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

√优点 简单 成本低

√缺点 发布过程中服务会中断 出了问题会影响全部用户

√适用 测试环境部署 小公司或者非核心的业务服务

image.png

金丝雀发布（试探性发布）

由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来,金丝雀发布由此得名。

优点：相对简单、能够用少量用户验证新版本功能

缺点： 发布过程中服务会中断 发现不了随用户量增大才会暴露的问题

适用 测试环境部署 小公司或者非核心的业务服务

image.png

滚动发布

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

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

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

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

image.png

蓝绿发布

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

优点 发布速度快 流程相对简单

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

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

image.png

红黑发布

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

√ 优点 发布速度快流程相对简单

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

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

image.png

小结

没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布

有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布

运维阶段

止损→周知→定位→修复

流程优化

方向

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

DevOps

  • 效率竖井

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

  • DevOps解决方案

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

全流程自动化

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

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

  • 减少无价值的等待

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