以下为字节青训营后端课程，后端开发与迭代——从需求到上线全流程的部分课程笔记记录：
从需求到上线全流程
为什么要有流程
个人开发者不需要流程；超过一个人的团队就需要协作；团队规模上升会有新问题；
人员&名词解释
RD：研发 RM：产品经理 PRD：需求文档 UED：用户体验设计 QA：测试 Scrum1：敏捷团队1 P0/P1：优先级0/优先级1 Backlog：规划列表
会议解释
Backlog Grooming Meeting-待办事项整理会议：产品负责人描述下个迭代希望实现的用户故事，PM提出需求列表 Sprint Planning Meeting-迭代计划会议：选择迭代的任务和估算工作量 Standup Meeting-每日站会：昨天做了什么？今天将要做什么？有需要帮助的地方吗？ Review Meeting-评审会：小组向产品负责人展示迭代工作结果 Retrospective Meeting-反思会：在每个迭代后召开简短的反思会，总结
有哪些流程
需求阶段
不要浪费时间讨论不应该存在的问题 MVP-Minimum Viable Product-最小化可行产品思想：站在用户的角度思考；收集用户反馈，快速迭代
开发阶段
代码规范：良好注释；重复逻辑抽象成公共方法 自测：单元测试，功能环境测试，测试数据构造 文档：大型改造要有技术设计文档，方案评审；好的接口文档能更方便的和前端进行沟通
测试阶段
单元测试-集成测试-系统测试-UI测试 越早发现缺陷修复成本越低
发布阶段
发布负责人：按照计划执行发布；通知各个相关人员发布进展；观察各个服务的发布状态，及时处理异常 值班同学：特别关注发布过程中的监控和告警，若有异常需要立刻判断是否由变更引起；如有变更引起的告警或用户反馈，需要及时终止发布
蛮力发布：简单粗暴，直接用新版本覆盖老版本。 简单成本低；发布过程中服务会中断，出问题会影响全部用户；适用测试环境部署，小公司或非核心的业务服务
滚动发布：每个实例都通过金丝雀方式逐步放大流量，对用户影响小，体验平滑 发布过程中用户体验不会中断，可以充分验证服务功能；流程较复杂，对发布系统要求高，发布速度慢，新老版本不兼容则不能使用；使用发布系统能力强，可以平滑切换流量，发布自动化程度高，可以自动滚动
蓝绿发布：把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级 发布速度快，流程相对简单；需要有一半机器承担所有流量的能力，出问题会影响全部用户；适用服务器资源丰富，需要一次性升级到新版，新老版本不能兼容的情况
红黑发布：和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务 发布速度快，流程相对简单；对机器数量仍然有要求，需要能扩容一倍，出问题会影响全部用户；适用服务器资源丰富，新老版本不能兼容的情况，需要一次性升级到新版
实际工作中使用的滚动发布 没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布 有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
