这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记。
实践中有哪些流程？
- 需求阶段
- 开发阶段
- 测试阶段
- 发布阶段
- 运维阶段
需求阶段
不应该浪费时间讨论不应该存在的问题
MVP（minimum viable product，最小化可行产品）思想：
- 要站在用户的角度思考
- 手机用户的反馈，快速迭代（首先应该给用户一个简单能够使用的产品，再逐步根据用户的反馈对产品进行升级。而不是给出产品的一部分（无法使用的产品））
四象限法：先判断事情的重要性，再判断紧急程度。
云原生下的开发
- 传统的虚拟机上进行服务开发，是在物理机或者是更底层上虚拟出多个虚拟主机，然后再每个虚拟主机中安装软件和依赖。虚拟机需要有专门的运维人员维护。
- 云原生开发的后端程序，容器时从操作系统中虚拟出来的，所有的容器共享宿主机的系统。通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销。后端开发不再依赖运维人员创建程序的运行时环境。
开发阶段
需要进行自测（单元测试、功能环境测试、测试数据构造）以及文档编写。
测试阶段
- 功能环境：需要一个能模拟线上的环境进行开发和测试，并且环境与环境之间能够隔离，不影响其他功能的开发和测试。（主要用于开发和测试新功能）
- 集成环境：不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷。（为了把不同的功能合并在一起测试）
- 回归环境：确保新的功能不对老的功能产生影响，回归测试一般会借助自动化测试脚本。（验证新的功能对老的功能没有影响）
发布阶段
- 蛮力发布：直接用新版本覆盖旧版本。
- 金丝雀发布：新版本替换部分的旧版本，然后再全部替换为新版本。
- 滚动发布：每个实例都会通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑。
- 蓝绿发布：将服务分成蓝绿两组，先将蓝组流量摘掉然后升级，使用绿组提供服务，之后切换全部流量，使用蓝组提供服务，然后升级绿组服务，最终两组全部升级。
- 红黑发布：与蓝绿发布类似，但是发布时会动态扩容出一组新的服务。
运维阶段
观察线上监控和日志。
