一线大厂:从需求提出到上线流程总结(一)
共 3586字,需浏览 8分钟
·
2021-08-13 01:40
在一线大厂,从需求提出到上线,整个流程是怎样的?笔者结合腾讯的工作流和调研了阿里、字节等公司的项目开发流程,发现大厂的工作流大同小异,总结了如下的整体流程图。
下面将按照这个流程的每个节点,详细阐述。全文3000多字,阅读大概需要6分钟~
目录
1、需求阶段
2、开发阶段
3、测试阶段
4、发布阶段
5、监控阶段
6、总结
1、需求阶段
1.1 原型评审
需求提出后,产品一般会带着原型图,拉开发、数据、设计一起开需求评审会。
在这个会议中,大家如果对需求有什么建议/意见都可以提出,如果需求实现不了、改动很大没法向前兼容、开发周期长等问题都可以在这个会议中抛出来,产品会做出相应的调整。
1.2 交互设计评审
大家对原型图都没有什么异议之后,就进入下一流程了。当设计出了设计稿之后,就拉着产品、前端一起评审交互设计稿。
这个评审会主要是看以下几个方面:
(1) 交互设计稿跟产品逻辑有没有一个比较大的出入;
(2) 组件风格跟整体风格是否统一;
(3) 在有产品上线有规定时间的条件下,UI还原复杂度如果占用开发时间比较长的话,会考虑让设计协调一个降级的方案。(比如复用以前的功能类似组件)
2、开发阶段
2.1 概要设计&排期
交互设计评审完之后,开发就可以开始排期了。(前端同学要到这个阶段才开始排期,但是后台、数据的同学一般原型评审完后就可以排期了)
开发是如何排期的呢?一般来说,一个需求开发出来到底需要多少时间,这个是不能百分之百准确评估的,因为有很多情况你没发预料,
比如线上出现bug,这个bug你可能要花一天的时间才能找到并修复,
再比如在你开发过程中,遇到一个难题,要花时间做调研等等。
所以开发排期一般都会留给自己一些buff(缓冲时间)。
要评估一个需求开发完需要花费多少时间,一般我们会先做一个概要设计,啥是概要设计?
概要设计就是实现这个需求的一个大概方案。一般会考虑以下几点:
(1) 考虑依赖
需求要实现依赖了哪些服务,包括第三方和我们自己的服务。
如果需要依赖第三方服务,需要调用第三方接口的话,可能还要去阅读第三方服务的接口文档和调用方式,也是需要一定的工作量的。
(2) 考虑复用
需求依赖的接口是否能复用,前端的组件是否能复用。如果组件可以复用的话,开发工作量是可以减少的。
(3) 考虑兼容性
需求实现之后,对已经存在的数据是否有冲突?对现有的功能是否有冲突?
比如说一个平台,以前用户的昵称是可以重复的,但最近产品提了一个需求是用户昵称不能重复,那么开发就需要对以前的用户昵称数据做一个修复,这也是一个工作量。
(4) 考虑技术盲点
如果遇到了不了解的技术盲点,可以申请一个调研的时间。因为技术选型也是需要调研和做竞品分析的 ,要找到最适合自己业务的技术选型。
概要设计一般会使用xmind等工具来把每一个功能涉及到的服务及影响写出来。
同时,概要设计也会给到测试同学,测试同学会根据你的概要设计,评估影响范围,新增、改动的接口有哪些,可以更全面的去写测试用例。
2.2 测试用例评审
这个环节测试同学会把测试用例拿出来评审,这时开发可以评估是否合理,或者有哪些点没有考虑到,都可以提出来。
2.3 接口定义与开发
如果这次需求涉及到新增、更改接口,是需要后端先定义一个接口协议的。比如一个查询订单的接口,需要提供哪些字段查询,返回的数据结构是怎样的。
后端提前定义好协议之后前端开发起来就顺畅很多了,因为数据结构已经都清楚了。
接下来开发们就开始写代码了。
2.4 开发自测
开发自测一般会在开发过程中完成。一般会做单元测试,性能测试等,根据具体需求而定。
对于前端,因为后台可能接口还没开发完成,但是这时又需要后台接口来测试,那怎么办呢?
我们一般会使用mock服务,mock就是模拟接口返回的服务。这样就可以大大提高了开发效率。
2.5 联调
当前后端都开发完,就开始联调啦。联调就是前端正式调用后台发布到测试环境的接口。这个阶段可能会出现后台漏字段、字段名变更、接口返回异常等问题。
在排期时联调也是需要把时间算进去的。
3、测试阶段
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、监控阶段
5.1 埋点统计
产品为了查看功能的使用情况,比如页面停留时长、点击量、访问量等,前端一般都会做埋点统计。
5.2 错误日志监控&性能监控
为了保证线上的稳定性,前端、后台都会接入错误日志上报,比如接口返回出错1分钟内次数达到10次,那就会给开发通知告警。
性能监控主要是为了保证服务的可用性。比如服务内存、cpu占用过大,或者某个接口在1秒内调用频率超过了限制,都会有告警。
6、总结
到这里就讲完了,可能有的小伙伴会觉得这个过程很长很复杂,有点小题大做了,有些节点没必要。
当然如果对于一些小需求,小改动有些环节是可以省去的。但是对于常规的需求,都这样规范起来的话,可以保证开发效率和产品质量。
我们可以看到一个需求从开发到上线涉及到了需求管理、代码管理、版本管理、发布管理、人员通知等关键节点,
在上古时期,这些节点之间是割裂的,没有一个工具或者平台可以把他们串起来,比如需求和代码的关联,代码和发布版本的关联。
而且,这些节点很多都可以用自动化工具来管理起来,比如当开发提交代码到测试分支后自动发布,自动通知产品验收。
在自动化方面,一般大公司都有相应的工具/平台来管理,后面的文章将会讲到自动化管理项目方面的内容。
---- end ----
---- 推荐阅读 ----