这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
Why
- 个人开发者是不需要流程的
- 超过一个人的团队就需要协作
- 随着团队规模上升，会出现全新的问题
- 五个阶段
- 需求阶段: 每个人都有自己的想法，团队决策需要有一个过程
- 开发阶段: 多人/多端协作开发，每个人有自己的安排，相互配合需要有个流程
- 测试阶段: 产物怎样交付，测试如何开展，BUG 怎么修都需要流程
- 发布阶段: 怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
- 运维阶段: 线上问题如何应急响应，处理用户反馈和线上问题需要有流程
- 传统模型
- 瀑布模型
- 敏捷开发
- 内容
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本，和用户沟通
- 框架：SAFe (The Scaled Agile Framework)
- 内容
- 精益产品开发
- 敏捷软件开发
- 系统思考
- 现代的 Scrum
- 敏捷教练 Scrum Master
- 产品负责人 Product Owner
- 敏捷团队 Scrum Team
- 敏捷发布火车 Agile Release Train
- 内容
- 内容
What
- 五个阶段
- 需求
- 不要浪费时间讨论不应该存在的问题
- MVP (minimum viable product，最小化可行产品) 思想
- 站在用户的角度思考
- 收集用户反馈，快速迭代
- 四象限法则
- 开发
- 云原生的发展改变了后端开发的工作
- 容器化成为主流
- 容器是在操作系统中虚拟出来的
- 通过 cgroup，namespace 和 Union Mount 等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个整体，打包成镜像交付
- 微服务取代单体架构
- 各个功能在不同的服务中
- 不同模块需要进行 RPC 通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
- 团队的分治策略
- 代码规范，自测和文档
- 代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要 copy 代码
- 正确使用 IDE 的重构功能, 防止修改错误
- 自测
- 单元测试
- 功能环境测试
- 测试数据构造
- 文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
- 代码规范
- 测试
- 功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
- 集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能
- 合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
- 回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
- 功能环境
- 发布
- 发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
- 变更服务的相关 RD
- 按照上线 checklist 检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证执行发布计划中的其他操作{如线上配置，数据处理等)
- 值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时中止发布
- 发布模式
- 没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
- 蛮力发布
- 直接全部更新
- 金丝雀发布
- 先在一台上发布，测试有无问题，再向其他机器发布
- 蛮力发布
- 有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
- 滚动发布
- 蓝绿发布
- 没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
- 发布负责人
- 运维
- 需求
优化流程
- DevOps 解决方案
- 内容
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
- 效率竖井
- 流程中实际产生价值的部分很短
- 大量的时间用在等待和传递上
- 人和人之间的沟通很慢
- 全流程自动化
- 通过效能平台串联各个阶段
- 需求发起研发流程的自动化
- 写代码，测试环境部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
- 减少无价值的等待
- 分析整个流程的耗时，计算真正产生价值的时间
- 不断优化流程，让有价值的流程时间占比上升
- 通过效能平台串联各个阶段
- 内容
