在一线大厂，从需求提出到上线，整个流程是怎样的？笔者结合腾讯的工作流和调研了阿里、字节等公司的项目开发流程，发现大厂的工作流大同小异，总结了如下的整体流程图。
下面将按照这个流程的每个节点，详细阐述。全文3000多字，阅读大概需要6分钟～
1、需求阶段
2、开发阶段
3、测试阶段
4、发布阶段
5、监控阶段
6、总结
1.1 原型评审
需求提出后，产品一般会带着原型图，拉开发、数据、设计一起开需求评审会。
在这个会议中，大家如果对需求有什么建议/意见都可以提出，如果需求实现不了、改动很大没法向前兼容、开发周期长等问题都可以在这个会议中抛出来，产品会做出相应的调整。
1.2 交互设计评审
大家对原型图都没有什么异议之后，就进入下一流程了。当设计出了设计稿之后，就拉着产品、前端一起评审交互设计稿。
这个评审会主要是看以下几个方面：
(1) 交互设计稿跟产品逻辑有没有一个比较大的出入；
(2) 组件风格跟整体风格是否统一；
(3) 在有产品上线有规定时间的条件下，UI还原复杂度如果占用开发时间比较长的话，会考虑让设计协调一个降级的方案。（比如复用以前的功能类似组件）
2.1 概要设计&排期
交互设计评审完之后，开发就可以开始排期了。（前端同学要到这个阶段才开始排期，但是后台、数据的同学一般原型评审完后就可以排期了）
开发是如何排期的呢？一般来说，一个需求开发出来到底需要多少时间，这个是不能百分之百准确评估的，因为有很多情况你没发预料，
比如线上出现bug，这个bug你可能要花一天的时间才能找到并修复，
再比如在你开发过程中，遇到一个难题，要花时间做调研等等。
所以开发排期一般都会留给自己一些buff（缓冲时间）。
要评估一个需求开发完需要花费多少时间，一般我们会先做一个概要设计，啥是概要设计？
概要设计就是实现这个需求的一个大概方案。一般会考虑以下几点：
(1) 考虑依赖
需求要实现依赖了哪些服务，包括第三方和我们自己的服务。
如果需要依赖第三方服务，需要调用第三方接口的话，可能还要去阅读第三方服务的接口文档和调用方式，也是需要一定的工作量的。
(2) 考虑复用
需求依赖的接口是否能复用，前端的组件是否能复用。如果组件可以复用的话，开发工作量是可以减少的。
(3) 考虑兼容性
需求实现之后，对已经存在的数据是否有冲突？对现有的功能是否有冲突？
比如说一个平台，以前用户的昵称是可以重复的，但最近产品提了一个需求是用户昵称不能重复，那么开发就需要对以前的用户昵称数据做一个修复，这也是一个工作量。
(4) 考虑技术盲点
如果遇到了不了解的技术盲点，可以申请一个调研的时间。因为技术选型也是需要调研和做竞品分析的 ，要找到最适合自己业务的技术选型。
概要设计一般会使用xmind等工具来把每一个功能涉及到的服务及影响写出来。
同时，概要设计也会给到测试同学，测试同学会根据你的概要设计，评估影响范围，新增、改动的接口有哪些，可以更全面的去写测试用例。
2.2 测试用例评审
这个环节测试同学会把测试用例拿出来评审，这时开发可以评估是否合理，或者有哪些点没有考虑到，都可以提出来。
2.3 接口定义与开发
如果这次需求涉及到新增、更改接口，是需要后端先定义一个接口协议的。比如一个查询订单的接口，需要提供哪些字段查询，返回的数据结构是怎样的。
后端提前定义好协议之后前端开发起来就顺畅很多了，因为数据结构已经都清楚了。
接下来开发们就开始写代码了。
2.4 开发自测
开发自测一般会在开发过程中完成。一般会做单元测试，性能测试等，根据具体需求而定。
对于前端，因为后台可能接口还没开发完成，但是这时又需要后台接口来测试，那怎么办呢？
我们一般会使用mock服务，mock就是模拟接口返回的服务。这样就可以大大提高了开发效率。
2.5 联调
当前后端都开发完，就开始联调啦。联调就是前端正式调用后台发布到测试环境的接口。这个阶段可能会出现后台漏字段、字段名变更、接口返回异常等问题。
在排期时联调也是需要把时间算进去的。
3.1 静态扫描
前后端联调完之后，就可以把代码发布到测试环境啦。测试环境是公司内网才可以访问的环境。在发布到测试环境之前，会自动触发一个工具的静态扫描。
静态扫描是啥呢？其实就是一个检测你的代码的工具。
一般会检查代码是否符合规范、代码是否有安全漏洞、依赖的第三方库是否安全等等，如果扫描过程中出现问题，会直接通知你，让你改进。
3.2 提测
代码发布到测试环境后，测试同学就开始测试啦。遇到什么bug的话，就会在需求管理平台给开发提bug单，开发收到之后就去解决。
这个阶段的周期看开发的质量和需求的大小。
3.3 产品第一次体验
bug都修复完之后，产品就开始在测试环境进行产品的第一次体验啦。
体验阶段，产品找出了bug，或者实现与需求有出入的地方都可以提给开发。
对于有设计稿的需求，设计这时也会参与进来走查还原度的问题。
产品&设计验收ok后，需求就可以发布到预发布环境体验真实的场景啦。
3.4 预发布环境体验
什么是预发布环境？预发布环境是为了模拟线上真实环境的体验环境，它跟线上环境唯一的区别是网址不同，其他的都一致。
为什么要有这么个环节呢？原因主要有2个：
一是线上数据与测试环境数据不同，想用线上数据做一些测试。二是为保证万无一失，看看新功能增加后，在线上环境会不会暴露出一些隐藏问题。
这个阶段不是必须的。还是具体情况具体分析。
4、发布阶段
4.1 制定发布计划
一般上线前，后台会找到相关的开发同学，制定一个发布计划。
因为当一个产品强大起来之后，它依赖的服务是非常多的，会涉及到一个发布顺序和对线上服务不可用的问题。
如果发布的是一个产品大版本，对线上完全不兼容，在服务发布时，如果线上有用户在使用，可能会导致操作失败或者引入脏数据。这都是我们不想要的结果。
对于这种情况，一般会采用2种方案，一种是暂时关闭线上服务，提示服务升级中。还有一种是关闭数据库的写操作，提示用户稍后重试。
4.2 灰度/全量发布
如果产品没有要求的话，默认使用全量发布，即对所有用户开放。
什么情况下会使用灰度发布？
(1) 降低发布带来的影响
虽然功能都在测试环境测过，但毕竟没有发布到生产环境，如果先让少部分用户先使用新版本，提前发现bug，或者性能问题，提前做好修复，就可以降低新版本带来的影响。
(2) 通过对新老版本的对比，观察新版本带来的效果。
具体的灰度发布细节可以看我以前写的这篇文章：大厂常用的几种灰度发布方案
4.3 产品第二次验收
当服务都发完后，产品需要到线上体验下新功能，看看有没有什么问题，保证万无一失。产品第二次验收完成后这个需求就算是完成了。
5.1 埋点统计
产品为了查看功能的使用情况，比如页面停留时长、点击量、访问量等，前端一般都会做埋点统计。
5.2 错误日志监控&性能监控
为了保证线上的稳定性，前端、后台都会接入错误日志上报，比如接口返回出错1分钟内次数达到10次，那就会给开发通知告警。
性能监控主要是为了保证服务的可用性。比如服务内存、cpu占用过大，或者某个接口在1秒内调用频率超过了限制，都会有告警。
到这里就讲完了，可能有的小伙伴会觉得这个过程很长很复杂，有点小题大做了，有些节点没必要。
当然如果对于一些小需求，小改动有些环节是可以省去的。但是对于常规的需求，都这样规范起来的话，可以保证开发效率和产品质量。
我们可以看到一个需求从开发到上线涉及到了需求管理、代码管理、版本管理、发布管理、人员通知等关键节点，
在上古时期，这些节点之间是割裂的，没有一个工具或者平台可以把他们串起来，比如需求和代码的关联，代码和发布版本的关联。
而且，这些节点很多都可以用自动化工具来管理起来，比如当开发提交代码到测试分支后自动发布，自动通知产品验收。
在自动化方面，一般大公司都有相应的工具/平台来管理，后面的文章将会讲到自动化管理项目方面的内容。
