开发流程
团队规模与流程的关系
- 需求阶段 -> 开发阶段 -> 测试阶段 -> 发布阶段 -> 运维阶段
软件生存期模型
-
瀑布模型
-
快速原型模型
-
增量模型
-
螺旋模型
-
喷泉模型
-
敏捷过程
-
敏捷软件开发宣言：
-
我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值。
-
-
流程拆解
需求阶段
-
和客户沟通，了解产品的目标是什么，客户想要实现什么
-
问题：
- 系统的目标或范围问题：系统边界不清楚，即哪些问题由计算机完成、哪些问题由手工方式解决不清楚
- 需求不准确问题：客户不能确定要什么，同一客户的不同需求相冲突
- 需求易变问题：随着时间推移，用户组织结构、业务流程以及外部业务环境可能发生变化
-
-
开发阶段：云原生下的开发
传统开发
-
传统虚拟机：
- 物理主机中虚拟出多个虚拟机，每个虚拟机有自己的操作系统
- 运维人员负责维护和交付虚拟机
- 每个虚拟机中都要安装相应依赖环境
-
单体结构
- 多个模块共同组成一个服务，服务体量较大
- 模块之间直接调用，不需要RPC通信
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
云原生开发
-
容器化
- 容器是在操作系统中虚拟出来的
- 通过cgroup、namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个真题，打包成镜像交付
-
微服务架构
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
-
云原生带来的其他变化
- 开发环境主键云原生化
- Faas，Paas等技术，让开发逐渐从本地IDE向线上转变
- 本来从入职到电脑搭建完一套开发环境要很久，现在通过WEB IDE等技术，环境未来将会开箱即用
合作开发
团队的分支策略
-
团队分支策略解决的主要问题：需要提前订下规范
- 多个团队成员之间各自用什么分支开发
- 修改之间有冲突如何解决
- 出了问题如何回退版本
开发规范
-
代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止修改错误
-
自测
- 单元测试
- 功能环境测试
- 测试数据构造
-
文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
概述
-
阶段：单元测试 -> 集成测试 -> 系统测试 -> UI测试
测试环境
-
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
-
集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
-
回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
发布阶段
发布过程中要做的事情
-
发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时理异常
-
变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作(如线上配置，数据处理等)
-
值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时中止发布
发布模式
- 蛮力发布：直接用新版本覆盖老版本
- 金丝雀发布：先发一小部分机器看看有没有问题，没问题再蛮力发布所有机器
- 滚动发布：每个实例都通过金丝雀发布
- 蓝绿发布：把服务分成蓝色绿色两组，先把蓝组的流量摘掉然后升级，只用绿组提供服务，之后切换全部浏览，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级
运维阶段
可能遇到的问题
- 用户量增加引起流量洪峰
- 数据库表的数据量增长导致查询速度变慢
- 内存/进程泄露导致服务资源不足
- 光缆被挖断
解决流程
- 止损 -> 周知 -> 定位 -> 修复
