从需求到上线全流程
前言
本人是个刚刚毕业的学生党，还没有参加过真正企业的项目开发，所以对于未知的情况还是比较好奇，学习了这一门课程，这里我不讲为什么要有流程和流程优化的一些事，只讲流程过程。
有哪些流程？
需求阶段
需求分析的重要性不言而喻，这是后续一切的目标。在这个阶段中，要有一种思想，MVP思想，这里的mvp是指minimum viable produce（最小可行产品）。
- 站在用户的角度思考
- 收集用户反馈，快速迭代
合理的时间安排：对于一个事情中，非常重要且不紧急的事情我们60%~80%的时间都要安排这些事，对于一些重要而且紧急的事我们要分配20%~25%的时间去处理，对于一些紧急的不重要的没必要去处理，还有一些不紧急不重要的事可以分配大概15%的时间，只有合理的安排时间，我们才能更好的处理这些事情，不论是大项目，还是我们自己的生活，这都是很有帮助的，再次谢谢老师的经验传授。
开发阶段
现在的开发大部分都是云开发，云原生的发展已经深刻改变了后端开发的工作。
-
云原生的开发
- 现在开发环境逐渐云原生化
- Faas, PaaS等技术，让开发逐渐从本地IDE向线上转变
- 从入职领到电脑搭完一套完整的开发环境需要很久，通过WEBIDE等技术，环境未来将会开箱即用
-
团队的分支策略
实际工作中一个项目的分支是有很多的，这个时候我们就会出现很多问题，在项目开发之前我们需要清晰下面这些问题
- 多个团队成员之间各自用什么分支开发？
- 修改之间有冲突怎么解决？
- 出了问题的代码如何回退到之前版本？
-
代码规范
- 需要养成良好的编程习惯，人大脑容量是有限的，超过三个月的代码，自己都不记得当时在想什么。
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止修改错误
-
自测
- 单元测试
- 功能环境测试
- 测试数据构造
-
文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档更方便的和前端进行沟通
测试阶段
测试阶段可以细分为UI测试，系统测试，集成设计，单元设计，其中越早发现缺陷问题修复的成本越低
-
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
-
集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
-
回归环境
- 确保新的环境不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
发布阶段
发布阶段有很多相关人员都有一些任务，这些可能每个都不相同，就不详细举例了
各种发布模式
-
蛮力发布：简单粗暴，直接用新版本覆盖老版本
- 优点：简单，成本低
- 确定：发布过程中服务会中断，出了问题会影响全部用户
- 适用：测试环境部署，小公司或者非核心业务服务
-
金丝雀发布
- 优点：相对简单，能够用少量用户验证新版本功能
- 缺点：发布过程服务会中断，发现不了随用户量增大才会暴露的问题
- 适用：测试环境部署，小公司或者非核心业务服务
-
滚动发布
- 优点：发布过程用户体验不会中断，可以充分验证服务功能
- 缺点：流程比较复杂，对操作系统有较高的要求，发布速度较慢，新老版本不兼容的情况下不能使用
- 适用：发布系统能力较强，可以平滑切换流量，发布自动化程度高，可以自动滚动
-
蓝绿发布
- 优点：发布速度快，流程相对简单
- 缺点：需要有一半机器承担所有流量的能力，出问题会影响全部用户
- 适用：服务器资源丰富，新老版本不能兼容的情况下，需要一次性升级到新版
-
红黑发布：与红绿发布类似，但是发布是会动态扩容出一组新的服务，而不是需要备用两组服务
- 优点：发布速度快，流程相对简单
- 缺点：对机器数量任然有要求，需要能扩容一倍，出问题会影响全部用户
- 适用：服务器资源丰富，新老版本不能兼容的情况下，需要一次性升级到新版
没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
