这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
团队规模和流程的关系
为什么要有流程？
- 个人开发者是不需要流程的；
- 超过一个人的团队就需要协作；
- 随着团队规模上升，会出现全新的问题；
复杂项目没有流程会有什么问题？
- 需求阶段：每个人都有自己的想法，团队决策需要有一个过程；
- 开发阶段：多人/多端协作开发，每个人都有自己的安排，相互配合需要有一个流程；
- 测试阶段：产物怎样交付，测试如何开展，BUG怎么修都需要流程；
- 发布阶段：怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范；
- 运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流畅；
传统的瀑布模型
- 工作流程的直观表达；
- 定义了标准的研发阶段；
- 以流程为本，理想化模型；
敏捷开发
- 以小团队快速迭代；
- 团队成员之间的合作更加紧密；
- 以人为本，和用户沟通；
The Scaled Agile Framework(SAFe)简介
SAFe是一套管理框架
- 精益产品开发；
- 敏捷软件开发；
- 系统思考；
字节团队的流程
有哪些流程
需求阶段
“不要浪费时间讨论不应该存在的问题”
需求阶段
MVP（minimun viable product，最小化可行产品）思想
- 站在用户的角度思考；
- 收集用户反馈，快速迭代；
优先：重要性，再看紧急。
开发阶段
云原生下的开发
传统虚拟机：
- 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统；
- 运维人员负责维护和交付虚拟机；
- 每个虚拟机中都要安装相应的依赖环境；
容器化：
- 容器是在操作系统中虚拟出来的；
- 通过cgroup、namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销；
- 应用和其依赖作为一个整体，打包成镜像交付；
单体架构：
- 多个模块共同组成一个服务，服务体量较大；
- 模块之间直接调用，不需要RPC通信；
- 服务整体扩缩容量；
- 多人开发一个代码仓库，需要充分集成测试；
微服务架构
- 各个功能在不同的服务中；
- 不同模块需要进行RPC通信；
- 不同模块可以独立扩缩容；
- 每个服务的代码仓库仅由少部分人维护；
开发环境逐渐云原生化
FaaS，PaaS等等技术，让开发逐渐从本地IDE向线上转变
从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用
团队的分支策略
代码规范、自测和文档
代码规范：
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么；
- 不要有魔法数字，魔法字符串（例如：莫名其妙的使用常数在 if 判断中）
- 重复的逻辑抽象成公共的方法，不要copy代码；
- 正确使用IDE的重构功能，防止修改错误；
自测：
- 单元测试；
- 功能环境测试；
- 测试数据构造；
文档：
- 大型改造需要有技术设计文档，方案评审；
- 好的接口文档能更加方便和前端进行沟通；
测试阶段
功能环境：
- 需要一个能模拟线上的环境进行开发和测试；
- 环境和环境之间能够隔离，不影响其他功能的开发和测试；
集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷；
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷；
回归环境
确保新的功能不对老的环境产生影响；
回归测试一般会借助自动化测试脚本；
发布阶段
各种发布模式
发布过程中要做的事情
发布负责人
- 负责按照计划执行发布；
- 需要通知各个相关人员发布进展；
- 观察各个服务的发布状态，及时处理异常；
变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警；
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证；
- 执行发布计划中的其他操作（如线上配置，数据处理等）
值班同学
-
发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起；
-
如果有变更引起的告警或者用户反馈，需要及时中止发布；
各种发布模式-蛮力发布
简单粗暴，直接用新版本覆盖老版本
优点：
- 简单；
- 成本低；
缺点：
- 发布过程中服务会中断；
- 出了问题会影响全部用户；
适用：
- 测试环境部署；
- 小公司或者非核心的业务服务；
各种发布模式-金丝雀发布
由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有毒气，因此得名
优点
- 相对简单；
- 能够用少量用户验证新版本功能；
缺点
- 发布过程中服务会中断；
- 发现不了随用户增大才会暴露的问题；
适用
- 测试环境部署；
- 小公司或者非核心的业务服务；
各种发布模式-滚动发布
每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑。
优点：
- 发布过程中用户体验不会中断；
- 可以充分验证服务功能；
缺点：
- 流程较复杂，对发布系统有比较高的要求；
- 发布速度较慢；
- 新老版本不兼容的情况不能使用；
适用：
- 发布系统能力较强，可以平滑切换流量；
- 发布自动化程度高，可以自动滚动；
各种发布模式-蓝绿发布
把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝绿提供服务，然后升级绿组服务，最终两组全部升级
优点：
- 发布速度快；
- 流程相对简单；
缺点：
- 需要有一半机器承担所有流量的能力；
- 出问题会影响全部用户；
适用：
- 服务器资源丰富；
- 新老版本不能兼容的情况，需要一次性升级到新版；
各种发布模式 - 红黑发布
和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务
优点：
- 发布速度快；
- 流程相对简单；
缺点：
- 对机器数量仍然有要求，需要能扩容一倍；
- 出问题会影响全部用户；
适用：
- 服务器资源丰富；
- 新老版本不能兼容的情况，需要一次性升级到新版；
没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
运维阶段
流程怎样优化
怎样让生活更美好
技术的发展会带来质量和效率的同时提高
将质量保障融入到流程，将流程自动化
从需求到上线全流程自动化，同时提高质量和效率
DevOps解决方案
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
效率竖井
- 流程中实际产生价值的部分很低；
- 大量的时间用在等待和传递上；
- 人和人之间的沟通很慢；
全流程自动化
通过效能平台串联各个阶段
- 需求发起研发流程的自动化；
- 写代码，测试环境部署的自动化；
- 自动化测试触发和报告分析；
- 发布过程可观测融入流程；
减少无价值的等待
- 分析整个流程的耗时，计算真正产生价值的时间；
- 不断优化流程，让有价值的流程时间占比上升；
