gitLab操作规范和项目流程

Posted 2022-10-31 sxldy

　　刚做完一个项目并且艰难得上线，对整个项目流程和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。最后会开项目总结会要记住 开会的时候总结的几点 ，最后会写项目总结 写到项目维基里。