这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记。
1.为什么要有流程
1.1 团队规模和流程的关系
1.个人开发者是不需要流程的
2.超过一个人的团队就需要协作
3.随着团队规模上升，会出现全新的问题
需求阶段:每个人都有自己的想法，团队决策需要有一个过程
开发阶段:多人/多端协作开发，每个人有自己的安排，相互配合需要流程
测试阶段:产物怎样交付，测试如何开展，BUG怎么修都需要流程
发布阶段:怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
运维阶段:线上问题如何应急响应，处理用户反馈和线上问题需要有流程
1.2 瀑布模型
需求—开发—测试—发布—运维
1.3 敏捷开发
1.个体和互动高于流程和工具 2.工作的软件高于详尽的文档
3.客户合作高于合同谈判 4.响应变化高于遵循计划
1.4 The Scaled Agile Framework (SAFe)
1.精益产品开发 2.敏捷软件开发 3.系统思考
2.有哪些流程
2.1 需求阶段
1.不要浪费时间讨论不应该存在的问题：四象限法
2.MVP (minimum viable product最小化可行产品) 思想：收集用户反馈
2.2 开发阶段
1.云原生下，应用和运行时容器共同作为交付产物
2.云原生开发与传统开发相比，区别在于部署形式和微服务架构
3.团队的分支策略—release分支
4.代码规范、自测和文档
代码规范：养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么；不要有魔法数字，魔法字符串；重复的逻辑抽象成公共的方法，不要copy代码；正确使用IDE的重构功能，防止修改错误
自测：单元测试；功能环境测试；测试数据构造
文档：大型改造需要有技术设计文档,方案评审；好的接口文档能更方便的和前端进行沟通
2.3 测试阶段
1.功能环境：需要一个能模拟线上的环境进行开发和测试；环境和环境之间能够隔离，不影响其他功能的开发和测试
2.集成环境：不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷；迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
3.回归环境：确保新的功能不对老的功能纷产生影响；回归测试一般会借助自动化测试脚本
2.4 发布阶段
发布过程中要做的事：
1.发布负责人：负责按照计划执行发布；需要通知各个相关人员发布进展；观察各个服务的发布状态，及时处理异常
2.变更服务的相关RD：按照上线checklist检查服务的日志，监控，响应上线过程中的告警；对于自己负责的改动，在小流量或者是预览环境进行功能验证；执行发布计划中的其他操作(如线上配置，数据处理等)
3.值班同学：发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起；如果有变更引起的告警或者用户反馈，需要及时中止发布
发布模式：
1. 金丝雀发布（小样本测试）
优点：相对简单；能够用少量用户验证新版本功能
缺点：发布过程中服务会中断；发现不了随用户量增大才会暴露的问题
适用：测试环境部署；小公司或非核心的业务服务
2. 滚动发布（每个实例通过金丝雀方式逐步放大流量）
优点：发布过程中用户体验不会中断；可以充分验证服务功能
缺点：流程较复杂，对发布系统有比较高的要求；发布速度较慢；新老版本不兼容的情况不能使用
适用：发布系统能力较强，可以平滑切换流量；发布自动化程度高，可以自动滚动
3. 蓝绿发布（服务分为蓝绿两组）
优点：发布速度快；流程相对简单
缺点：需要有一半机器承担所有流量的能力；出问题会影响全部用户
适用：服务器资源丰富；新老版本不能兼容的情况，需要一次性升级到新版
4.红黑发布（和蓝绿发布类似，但发布时会动态扩容出一组新的服务）
2.5 运维阶段
用户量增加引起流量洪峰；数据库表的数据量增长导致查询速度变慢；内存/进程泄漏导致服务-资源不足；光缆被挖断
3.流程怎么优化
3.1 怎样让生活更美好
1.在重视质量的团队，效率往往比较低；重视效率的团队，事故往往比较多
2. 技术的发展会带来质量和效率的同时提高；将质量保障融入到流程，将流程自动化；从需求到上线全流程自动化，同时提高质量和效率
3.2 DevOps
1.代码管理 2.自动化测试 3.持续集成 4.持续交付
3.3 全流程自动化
1.通过效能平台联各个阶段：需求发起研发流程的自动化；写代码，测试环境部署的自动化；自动化测试触发和报告分析；发布过程可观测融入流程
2.减少无价值的等待：分析整个流程的耗时，计算真正产生价值的时间；不端优化流程,让有价值的流程时间占比上升
