gitLab操作规范和项目流程

  刚做完一个项目并且艰难得上线,对整个项目流程和gitLab规范 有了一些心得,给新来的同学普及一下。

  最先产品会写一篇需求文档,咱们要先看需求文档对项目有一个大致了解,然后产品喊后端、ui、前端  一起在讨论-一下项目,对项目有一个明确的认知,如果讨论过程中 有咱们没有做过功能,咱们需要调研。 ui画完图 咱们先看图  想想一下项目的整个交互流程   感觉哪地方逻辑不对 可以和ui、产品一起商量,商量的时候记得叫上后端,别你们商量好了有改动  人家后端还不知道怎么回事那。 如果一些布局 你看着难受别扭,可以和ui商量 但是以ui为主,毕竟人家是 干这个的,还有刚来咱们公司 肯定会遇到没psd图  你没法量 但是还需要符合规范的情况,三种方式  你要求ui出psd图 、 还有就是 自己看《web端交互规范》和让ui 在图上标识距离像素。一般都是第三种,但是 由于咱们有组件库 通常情况下 都是不用测量距离。

  对项目有明确认知 就可以开始画类图,类关系用什么标识连接点开这个链接有详细说明 https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html  ,不会画 或者 类关系不明白的 可以问各自师傅,类图是重中之重  真正开始写代码的时候 是要跟根据类图来做的。mock在这个时候 也可以与后台制定了。

  然后ui图出完之后,咱们就可以开始画交互时序图了,交互时序图要体现出 用户的操作流程和交互效果,交互时序图画完要给ui看一下,哪地方的交互有问题 ui会和你说的。

  图画完让师傅或者组长检查一下,然后就可以开始预演了,预演就是 你拿着这两个图,给团队其他成员 去讲解,尤其是 交互时序图 需要和团队成员达成思想一致,才算预演成功。预演通过后,需要在gitLab上自己所在项目拆分issue,

  

 

   当然项目中的第一个issue 是标题:开发预演 描述:如:考试项目v1.0里程碑,预演结果--包括交互时序图和组件的类图,评论里面 发送 交互时序图和类图,开发预演issue通过了,并且组长评论了就可以关闭开发预演issue了。

  创建某个issue时 需要在该issue下 评论预估时间如 /estimate 2h, h时小时、d是天数。

  完成issue时 需要评论实际时间 /spend 2h  如果实际时间超出预估时间,要评论超出时长原因。

  完成一个issue的流程  :

     创建issue 如上图----评论预估完成该issue时间----准备完成某issue更改标记、选择截至日期----代码完成时push到对象issue的分支上-----在该issue上评论实际时间--如果超时在评论超时原因---把该issue合并到dev上

  完成所有issue 准备提测,提测之前需要进行代码评审,创建代码评审issue 如果有被审查出来的问题 描述里面把每个问题都写上,每个问题再单独创建一个issue,如果没有问题,找这次评审的负责人 进行评论通过,然后dev合并release

  

 

  dev合并release之前 需要配置好webpack,向运维要你项目的测试地址,向后端要后端的服务测试地址。

  合并到release 并且项目 能运行了,就算是提测成功,在测试期间 如果测试给你找到bug 他会创建issue 并把issue 指派给你,如果你发现是后端问题 你在和测试说 让他指派给后端,领到issue后评论issue预估时间、更改结束时间,完成后需要评论实际完成时间,分支名字根据下图来创建:

然后你就把你的fix/xxx分支,合并到dev在合并到release并且指派给测试,然后关闭该issue。

  测试完毕后,测试会创建预上线通知,咱们前端会在预上线issue里面检查并勾选检查项,然后测试把relase合并到master指派给产品,产品合并后关闭上线通知issue,在线上如果找到bug 产品会创建RC里程碑,线上bug issue指向RC里程碑,创建分支时要在master分支上创建,完成bug 分支hotfix/xxx合并dev,dev直接合并到master。

  最后项目线上没有问题后,master在合并 回dev和release。最后会开项目总结会要记住 开会的时候总结的几点 ,最后会写项目总结 写到项目维基里。

猜你喜欢

转载自www.cnblogs.com/sxldy/p/11484975.html
今日推荐