一、 流程
1. 瀑布模型
该模型比较传统，具体流程是需求阶段、开发阶段、测试阶段、发布阶段、运维阶段。这是一种理想化模型，特点是流程标准、直观。弊端也很明显，因为该模型过于重视流程本身，面对变幻莫测的市场难以招架。于是就引出另一种开发流程：敏捷开发
2. SAFe（全称：The Scaled Agile Framework）
是一套管理框架，融入了敏捷软件开发、精益产品开发和系统思考，不再是过于拘泥流程本身。如果用类比的方式，瀑布模型好比是古代打仗的方阵，而SAFe如同特种作战小队，其对应的scrum结构如下：
- 敏捷教练：小队队长
- 产品负责人：负责联络指挥部、发布任务的人
- 敏捷团队：其他特种兵
- 敏捷发布火车：不再按照方阵式推进，以一种更敏捷的方式
3. 一些名词的解释
- RD: 研发
- PM: 产品经理
- PRD: 需求文档
- UED: 用户体验设计
- QA: 测试
- Scrum: 敏捷团队
- P1/P1: 优先级0/优先级1
- Backlog: 规划列表
二、 各阶段具体介绍
1. 需求阶段
- 需求阶段的大忌：在不该存在的问题投入大量时间和精力
- 需求阶段的常规操作：砍需求（懂事的PM会主动把关然后砍需求）
- MVP（最小化可行产品）：站在用户角度思考问题，快速迭代。比如：用户想要一辆车，第一天给他一个轮子，第二天给他两个…最后才给他车，如此是错误。正确的思路应该是：第一天给他一个滑板、第二天给他自行车…最后给他一辆车。由此可见，对于产品的迭代，应大致让用户体验到用户想体验的东西，哪怕初期只有3~5成。
- 另一种评估需求的方法：四象限法 这种方法经常能在网络上看到，大致按照紧急、重要、不紧急、不重要进行划分。优先级通常先看重要程度，再看紧急程度，如果重要但不紧急的事情被拖延，就有可能演变为紧急且重要，紧急且重要的事情越多对自己越不利。
2. 开发阶段
与过去相比，现在的后端开发需要云原生、容器技术作为基础，比如：Kubernetes、Docker。
（1）传统虚拟机VS容器化
①传统虚拟机：
物理主机虚拟出多个虚拟机，每个虚拟机有自己的操作系统，由运维人员交付，并且虚拟机也是需要由运维人员维护
②容器化：
由操作系统虚拟出来，特点是开销低、容器之间隔离，不再依赖运维人员创建程序运行时的环境。容器实现了应用和依赖融为一体，所以解决了：“明明项目在我的电脑跑得好好地，怎么换了个环境就跑不起来了…” 的问题
（2）单体架构VS微服务架构
①单体架构
所有模块集中在一个服务中，优点是各模块之间访问无需RPC通信，可以直接调用。弊端也很明显，如果所有模块加起来非常庞大，那么对整个项目的维护需要更多的时间精力，或者说，在完成开发后，需要更充分的集成测试
②微服务架构：
将不同的模块分散在不同的服务中，服务之间访问需要RPC通信，这就造成了网络开销大。而它的优点是延展性强，不同的模块可以独立扩容，每个服务的代码仓库只需要少部分人即可维护。举个例子：在开发即时通信系统会有登录功能，登陆由两个或两个以上模块实现，需要对用户登录的信息进行验证，查询账号或密码是否存在，需要一个模块实现，登录成功后又需要显示该用户对应的信息（联系人、消息等），这就需要另外的模块来实现。
（3）团队分支策略
通常开发团队的成员会根据主干的某个版本进行修改，在修改后进行合并。好比是一艘某版本的战船需要修改或添加个功能，工程师们根据各自的任务对战船的某部件进行修改、测试，完成各自的任务后，再统一将修改后的部件合并，一个修改后的战船就此新鲜出炉。 在团队分支策略中，也会面临诸如：使用什么分支？修改发生冲突怎么办？代码出问题怎么回滚？ 对于以上问题，有两种方案，分别是使用release分支和利用master的commit发布。
- 前者是团队各成员把代码并入release分支，然后再测试和发布，最后合并到master中。
- 后者是团队各成员把代码并入master，再使用某个master的commit发布。 在后续的测试阶段和发布阶段中，会根据分支和commit进行交付
（4）代码规范、自测、文档
① 代码规范：
- 对于重复的逻辑，直接写成公共方法供其他地方直接调用即可，不需要再copy。
- 对于重构，应当正确地使用IDE，避免手动局部修改和全局替换。
- 对于命名和注释，应当养成良好的习惯，注重可读性，避免使用类似魔法字符或魔法数字。
② 自测和文档：
在开发阶段还应当进行自测和编写文档，这将会对整个团队都有良好的影响。
3. 测试阶段
① 四个测试：
- 单元测试：对项目最小可以测试的地方进行测试
- 集成测试：将单元按照设计要求组合起来，进行测试（能够通过单元测试不一定就代表可以通过集成测试，比如客户端可以正常向服务端发生请求，服务端也能正常响应请求，然而客户端在接收并处理返回的数据时报错，可能是因为数据格式对不上，也可能客户端根本无法解析该数据等）
- 系统测试：即对整个系统的测试，通常是把软件、硬件、操作人员视作整体。
- UI测试：通常测试界面是否友好，其风格、控件及布局是否符合用户使用习惯等
② 三个环境：
- 功能环境：模拟线上环境开发和测试、环境之间隔离 互不影响
- 集成环境：不同人员开发的功能合并测试，其相互的影响可能会产生缺陷；迭代发布的功能合并测试可以保证所有功能之间的影响不产生缺陷。
- 回归功能：通常借助自动化测试脚本进行测试，保证新添加的功能不会影响原先的功能
4. 发布阶段
- 需要做的事情：
① 发布负责人：按照计划发布项目、通知相关人员发布进展、观察各服务发布状态，捕捉异常要及时处理
② 变更服务的相关RD：检查服务日志、监控，响应项目上线过程的告警
执行计划中的操作（线上配置、数据处理）
③ 值班人：关注项目发布过程的监控、告警，判断是否由变更引起异常
如果是由变更引起的告警或用户反馈，及时终止发布。
发布模式：
① 适用于小公司、非核心业务服务
- 蛮力发布：直接新版覆盖旧版，简单成本低但是过程中服务可能会中断
- 金丝雀发布： 让少量用户验证新版本功能，相对简单，缺点同上。
② 适用于发布系统能力强、自动化程度高
- 滚动发布：每个实例都采用金丝雀发布，对用户影响小，发布过程用户体验不中断，充分验证服务功能，但是流程较为复杂，对发布系统要求高，新老版本不兼容的情况下不能用。
③ 适用于服务器资源丰富，新老版本不兼容的情况下需要一次性升级到新版本。
- 蓝绿发布：服务分为蓝绿组，摘掉蓝组流量并且升级，只用绿组通过服务，而后全部切换流量，只用蓝组提供服务，最后两组都升级。优点是发布速度快、流程简单，缺点是需要一半机器承担所有流量的能力，所以需要服务器资源丰富，并且如果出问题，全部用户都会被影响。
- 红黑发布：与蓝绿相似，在此基础上，发布时动态扩容新的服务，因此无需常备两组服务。
5. 运维阶段
发布后出现的问题：
- 流量洪峰
- 数据库数据表的数据量增长
- 内存/进程池泄露导致服务资源不足
- 光缆事故
