这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
1、团队规模和流程的关系
如果复杂度很高的项目没有流程会出现什么问题：
①需求阶段：每个人都有自己的想法，团队决策需要有一个过程
②开发阶段：多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程
③测试阶段：产物如何交付，测试需要如何开展，BUG怎么修都需要流程
④发布阶段：怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
⑤运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程
2、有哪些流程
①需求阶段：
需求评估方法
1)MVP思想
·站在用户的角度思考
·收集用户反馈，快速迭代
2)四象限法
当任务过于繁重的时候，我们可以将任务的重要性和紧急程度进行分类。可以将既重要又紧急的事情先去做，不重要又不紧急的事情可以最后做。这个理论的原则是先判断事情的重要性，再判断紧急程度。
②开发阶段：
现在主要是云原生下的开发，其优点主要体现在以下方面：
1)云原生下的开发，一个最大的区别就是部署的形式不同，传统虚拟机上的服务开发，是在物理机或者更底层上虚拟出多个虚拟机，然后在每个虚拟主机中安装软件和依赖虚拟机需要有专门的运维人员维护，本地开发的时候也大多是直接在电脑上运行程序。而开发云原生的后端程序，容器是从操作系统中，虚拟出来的，所有容器共享宿主机的系统，通过cgroup，namespace和union mount实现了容器之间的隔离，因此在部署的时候，应用和其依赖的系统是整体打包成一个镜像的，后端开发不再依赖运维人员创建程序的运行时环境。
2)云原生带来的另外一个改变就是微服务，在之前几年，web应用的主要架构师SOA架构，在一个服务中多个不同的模块构成了一个部署单元，各个模块作为一个整体部署和伸缩。这种架构下往往服务会形成一个很大的代码仓库，大家共同维护一个大型的系统。好处是模块之间的调用不需要通过RPC，但是坏处就是加减机器的时候不能按模块处理。开发的工作也需要多人共同进行充分的集成测试，保证不会把别人的东西改坏。而微服务架构是把模块拆分到不同的服务器中去，拆分的力度更加细，可以让每个模块独立的扩容/缩容。同时可以让少数几个人维护一个仓库，更适合敏捷的开发流程。
在开发阶段代码的规范，自测和文档也是非常重要的。
③测试阶段：
测试成本由高到低的测试分别为：UI测试、系统测试、集成测试、单元测试。所以越早发现的缺陷解决成本越低，我们尽可能早的发现bug，进行充分的单元测试。
④发布阶段：
有如下几种发布模式：
1)蛮力发布
优点：简单、成本低
缺点：发布过程中服务会中断，出了问题会影响全部用户
适用：测试环境部署，小公司或者非核心的业务服务
2)金丝雀发布
优点：相对简单，能够用少量用户验证新版本功能
缺点:发布过程中服务会中断，发现不了随用户量大才会暴露的问题
适用：测试环境部署，小公司或者非核心的业务服务
3)滚动发布
优点：发布过程中用户体验不会中断，可以充分验证服务功能
缺点：流程较复杂，对发布系统有比较高的要求，发布速度慢，新老版本不兼容的情况不能使用
适用：发布系统能力较强，可以平滑切换流量。发布自动化程度高，可以自动滚动
4)蓝绿发布
优点：发布速度快，流程相对简单
缺点：需要有一半机器承担所有流量的能力，出问题会影响全部用户
适用：服务器资源丰富，新老版本不能兼容的情况，需要一次性升级到新版
5)红黑发布
优点：发布速度快，流程相对简单
缺点：对机器数量仍然有要求，需要能扩容一倍，出问题会影响全部用户
适用：服务器资源丰富，新老版本不能兼容的情况，需要一次性升级到新版
小结：没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布。有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布。
⑤运维阶段
