gitLab操作规范和项目流程

2019/09/14 17:20
阅读数 35

  刚做完一个项目并且艰难得上线,对整个项目流程和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
 

   我们开始开发功能是在dev上创建分支,功能分支 就是开发项目里面还没有的新功能的分支,以dev-feat开头。功能开发完之后确定没有问题,合并到dev,如果合并到dev之后发现有问题要修复,在dev分支上建bug修复分支,以dev-fix开头,修复完之后合并回dev,功能全部开发完毕。

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

  

 

 

 

 

 

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

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

 

在测试环境发现的问题,在release分支上创建分支,以fix开头,修复完合并回release 指派给测试,测试合并后,然后关闭该issue。

  测试完毕后,测试会创建预上线通知,咱们前端会在预上线issue里面检查并勾选检查项,然后测试把relase合并到master指派给产品,产品合并后关闭上线通知issue,在线上如果找到bug 产品会创建RC里程碑,线上bug issue指向RC里程碑,在master分支上创建分支,以hotfix开头,修复完合并回master指派给运维,运维合并后,然后关闭该issue。

  项目线上没有问题后,master合并到dev,项目负责人自己提合并请求,自己完成合并,然后将dev合并到release ,测试组同事完成合并。最后会开项目总结会要记住 开会的时候总结的几点 ,最后会写项目总结 写到项目维基里。

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部