这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记
为什么要有流程
团队规模和流程的关系
- 个人开发者是不需要流程的
- 超过一个人的团队就需要协作
- 随着团队规模上升，会出现全新的问题
复杂项目没有流程会有什么问题
- 需求阶段:每个人都有自己的想法，团队决策需要有一个过程
- 开发阶段:多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程
- 测试阶段:产物怎样交付，测试如何开展，BUG怎么修都需费流程
- 发布阶段:怎样确保发行过程平稳丝滑。版本和流星如何控制，需要有规范
- 运维阶段:线上问影如何应急响应，处理用户反馈和线上问题需要有流程
传统的瀑布模型
一个最直观的流程模型
- 工作流程的直观表达
- 定义了标准的研发阶段
- 以流程为本，理想化模型
敏捷开发
更现代的流程模型
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本，和用户沟通
The Scaled Agile Framework (SAFe)简介
SAFe是一套管理框架
- 精益产品开发
- 敏健软件开发
- 系统思考
现代的Scrum
- 敏捷教练Scrum Master
- 产品负责人Product Owner
- 敏键团队Scrum Team
- 敏键发布火车Agile Release Train
团队的流程
人员&名词解释
- RD:研发
- PM:产品经理
- PRD:需求文挡
- UED:用户体验设计
- QA:测试
- Scrum1:敏捷闭队1
- P0/P1:优先级0/优先级1
- Backlog:规划列表
会议解释
- 待办事项整理会议(Backlog Grooming Meeting)
- 产品负责人描述下个迭代希望实现的用户故事，PM提出需求列表
- 迭代计划会议(Sprint Planning Meeting)
- 选择法代的任务和估算工f作量
- 每日站会(Standup Meeting)
- 昨天你做了什么?
- 今天你将要做什么?
- 你有需要帮助的地方吗?
- 评审会(Review Meeting)
- 小组向产品负责人展示迭代工作结果
- 反思会(Retrospective Meeting)
- 在每个迭代后召并简短的反思会，总结哪些事情做得好，哪些事情做得不好
有哪些流程
需求阶段
不要浪费时间讨论不应该存在的问题
特斯拉进行生产线自动化的时候，有一个零件的安装自动化总是出问题，特斯拉的工程师为了优化这个自动化流程,投入了大量的资金和精力。 后来马斯克问他们的技术人员，为什么需要这个零件，结果发现大家居然并不清楚。最后证明其实在电动车上，根本不需要这个零件。 所以围绕着这个不应该存在的问题，进行了大量投入，造成了很多浪费
MVP(minimum viable product,最小化可行产品)思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
如果我们要给用户造一辆车，我们不应该第一天给他一个轮子，第二天给两个轮子，第三天给他一个底盘，第四天才让他开上车
我们应该先给用户一个简单能用的产品，比如一个滑板车，一个自行车，根据用户的反馈我们再逐步把车的功能升级，最终变成用户想要的产品
- 这个理论的原则是先判断事情的重要性，再判断紧急程度
- 一个高效的占比，应该是大多数时间在处理重要但不紧急的事情，因为一旦一件事情变成了紧急，那我们就容易犯错误，因此如果每天大部分时间都在处理重要且紧急的事情，那么其实是不健康的
开发阶段
云原生的发展，深刻改变了后端开发的工作
- 传统虚拟机
- 在物理主机中虚似出多个虚似机，每个虚拟机拥有自己的操作系统
- 运维人员负责维护和交付虚拟机
- 每个虚拟机中都要安装相应的依赖环境
- 容器化
- 容器是在操作系统中虚拟出来的
- 通过cgroup,namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个整体，打包成镜像交付
云原生下的开发
- 单体架构
- 多个模块共同组成一个服务，服务体量较大
- 模块之问直接调用，不需要RPC通信
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
- 微服务架构
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
- 开发环境逐渐云原生化
- FaaS,PaaS等等技术，让开发逐渐从本地IDE向线上转变
- 从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用
团队的分支策略
- 有些团队会有一个专门的分支叫做release分支，大家都把代码合并到release分支，然后测试，发布，之后再把release分支合回master
- 有些团队会直接把开发的分支合入master,然后再用某个master上的commit发布
- 之所以有各种各样的分支策略，就是因为我们在后续的测试和发布阶段要按照对应的分支和commiti进行交付
代码规范、自测和文档
- 代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码.
- 正确使用IDE的重构功能，防止修改错误
- 自测
- 单元测试
- 功能环境测试
- 测试数据构造
- 文档
- 大型改造需要有技术设计文档,方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
你需要在写完每一段代码之后立刻测试这段代码，当完成了更多的代码时，就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分，质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。
—《Google软件测试之道》
- 功能环境
- 需要个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
- 集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在—起测试,确保发布的所有功能之间的影响不产生缺陷
- 回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
发布阶段
- 发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
- 变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作(如线上配置，数据处理等)
- 值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈,需要及时中止发布
发布模式
蛮力发布
简单粗暴，直接用新版本覆盖老版本
- 优点
- 简单
- 成本低
- 缺点
- 发布过程中服务会中断
- 出了问题会影响全部用户
- 适用
-
测试环境部署
-
小公司或者非核心的业务服务
-
金丝雀发布
由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。
- 优点
- 相对简单
- 能够用少量用户验证新版本功能
- 缺点
- 发布过程中服务会中断
- 发现不了随用户量增大才会暴露的问题
- 适用
- 测试环境部署
- 小公司或者非核心的业务服务
滚动发布
每个实例都通过金丝雀的方式逐步放大流量。对用户影响小，体验平滑
- 优点
- 发布过程中用户体验不会中断.
- 可以充分验证服务功能
- 缺点
- 流程较复杂，对发布系统有比较高的要求
- 发布速度较慢
- 新老版本不兼容的情况不能使用
- 适用
- 发布系统能力较强，可以平滑切换流量·
- 发布自动化程度高，可以自动滚动
蓝绿发布
把服务分成蓝绿两组，先把蓝组流星摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级。
- 优点
- 发布速度快
- 流程相对简单
- 缺点
- 需要有一半机器承担所有流量的能力
- 出问题会影响全部用户
- 适用
- 服务器资源丰富
- 新老版本不能兼容的情况，需要—次性升级到新版
红黑发布
和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务。
- 优点
- 发布速度快
- 流程相对简单
- 缺点
- 对机器数量仍然有要求，需要能扩容—倍
- 出问题会影响全部用户
- 适用
- 服务器资源丰富
- 新老版本不能兼容的情况，需要—次性升级到新版
没有强大发布系统和服务器资源不足的公司—般使用蛮力发布或者金丝雀发布
有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
运维阶段
流程怎样优化
怎样让生活更美好
在重视质量的团队，效率往往比较低
在重视效率的团队，事故往往比较多
- 技术的发展会带来质量和效率的同时提高
- 将质量保障融入到流程，将流程自动化
- 从需求到上线全流程自动化，同时提高质量和效率
DevOps
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
- 效率竖井
- 流程中实际产生价值的部分很短
- 大量的时间用在等待和传递上
- 人和人之间的沟通很慢
全流程自动化
- 通过效能平台串联各个阶段
- 需求发起研发流程的自动化
- 写代码，测试环境部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
- 减少无价值的等待
- 分析整个流程的耗时，计算真正产生价值的时间
- 不断优化流程，让有价值的流程时间占比上升
