目录
一、走进后端开发流程
1、传统流程
2、敏捷开发
3、SAFe简介
4、字节团队的开发流程
二、开发流程详解
1、需求阶段
2、开发阶段
云原生开发
团队的分支策略
自测
3、测试阶段
4、发布阶段
简单发布
金丝雀发布
滚动发布（推荐）
蓝绿发布（推荐）
5、运维阶段
3、流程优化
DevOps解决方案
一、走进后端开发流程
1、传统流程
需求、开发、测试、发布、运维，一个阶段完全好了，再到下一个。
2、敏捷开发
更注重的是个体的互动、工作的软件、客户合作、响应变化
更现代的流程模型
- 以小团队快速迭代
- 团队成员之间合作更密切
- 以人为本，和用户沟通
不停的快速迭代，每个迭代都包含之前的需求开发测试发布运维的过程。
3、SAFe简介
SAFe是一套管理框架，帮助团队间的合作开发
可见，现代的开发已经不像之前那样了，我们现在开发主打就是敏捷快速。
4、字节团队的开发流程
可见事件中的开发并不是写完测试上线就行，还是有很长的录要走的
二、开发流程详解
1、需求阶段
MVP(minimun viable product,最小化可行产品)思想
去掉一些不需要的需求，留下必要的
站在用户角度思考，收集用户反馈，快速迭代
把重要和紧急的事情先做，重要放在前面，紧急放在重要后面。
2、开发阶段
云原生开发
云原生的发展，深刻改变了后端开发的工作，从原本的单机到云上部署
微服务架构，我们把每个模块都差分开，分成一个个服务，每个人开发的都是独立的一个个服务，这样就减小很多人开发一个项目的弊端。但是不同的服务之前会有rpc通信，网络的开销会越来越大。
FaaS、Paas等技术让开发从本地ide向线上转变，我们入职到搭建环境要很久，我们可以通过云原生的web ide等技术，环境未来将会开箱即用，打开就可以用直接编码，里面已经配好的各种需要的依赖
团队的分支策略
多个团队成员之前各自用什么分支开发
修改之间有冲突怎么解决
出了问题代码如何退回之前版本
这些git的使用，什么时候合并和回退必须得搞清楚
自测
单元测试
功能环境测试
测试数据构造
3、测试阶段
为自己的代码负责，自己要提前保证代码的质量。从底层的单元测试到继承测试到系统测试都要做好，最后系统测试和ui测试出问题的维护成本远远大于一开始的小方法，所有没写完都要测试一下，尽可能早发现bug。
功能环境：测试功能，而且不影响其他功能开发和测试
继承环境：不同开发功能合并一起测试，相互之间不能影响，确保发布所有功能不产生缺陷
回归环境：确保新功能不会对老功能影响，一般借助自动化测试脚本
4、发布阶段
发布之前要查询检查一遍，观察每个服务的发布状态，及时处理异常
发布过程中监视和告警需要特别关注，如果有异常立刻判断是否由变更引起，如果是变引起或用户反馈，及时终止发布。
简单发布
直接用新版本覆盖老版本
优点：简单、成本低
缺点：发布过程中服务会中断，出了问题会影响全部用户
适用：测试环境部署，小公司或非核心业务
金丝雀发布
由于金丝雀对瓦斯非常铭感，因此以前开矿下矿洞，先放一只金丝雀进去探是否有毒气体，看到金丝雀能否活下来，金丝雀发布由此得名。先发一台服务看看是否有问题
优点：相对简单，能用少量用户验证新版本功能
缺点：发布过程中服务也会中断，发现不了随用户增大才会暴露的问题
适用：测试环境部署，小公司或非核心业务
滚动发布（推荐）
每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
优点：发布过程中用户不会中断，可以充分验证服务功能
缺点：流程复杂，对发布系统比较高的要求，发布速度慢，新老版本不兼容的情况不能用
适用：发布系统能力较强，可以平滑切换流量，发布自动化程度高，可以自动滚动
蓝绿发布（推荐）
把服务分为蓝绿两组，先把蓝组流量摘除然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终全部升级
优点：发布速度快，流程相对简单
缺点：需要对一般机器承担所有流量的能力，出问题影响全部用户
使用：服务器资源丰富，新老版本不能兼容的情况，需要一次性升级到新版
半夜流量一般比较低，适合做发布，所有这就是大部分后端开发都工作时间比较晚的原因
5、运维阶段
服务可能因为各种原因出故障。
一般公司会有检测的平台，方便我们第一时间发现问题解决问题。
3、流程优化
之前的流程有很多繁琐的步骤和流程。当我们的流程越繁琐，我们的质量可能会越高，但是这样效率比较低。我们不可能同时兼顾质量和效率。
我们要把质量和效率都要提高。
DevOps解决方案
把开发和运维形成一个闭环。从需求、开发、测试、发布、运维，这几个步骤不断的循环运转，有了这个我们就能不断的持续继承和交付。
流程中实际产生价值的部分很短，大部分时间都在等待和传递，开发在等别的开发，开发在等运维等待。
