likes
comments
collection
share

我在公司开发一个项目会经历什么

作者站长头像
站长
· 阅读数 18

我报名参加金石计划1期挑战——瓜分10万奖池,这是我的第7篇文章,点击查看活动详情

心血来潮,整理下,日常开发项目,怎么做才是符合公司的一整套规范的自己在代码层面都需要做些什么,才是符合公司的规范。

使用的相关工具,仓库使用GitLab,项目管理工具Git、项目管理使用Jira

项目流程规范

日常开发一下项目,要经过多个场景。

  1. 首先一个需求,会先到产品经理那里,产品进行过滤后最终产出产品需求文档prd(Product Requirement Document)
  2. prd产出后,产品经理会寻找本次相关人员,进行需求评审会议,多方人员舌战群儒,愉快的会议过后;
  3. ui同学会根据prd并和产品简单对一下后产出ui稿,并发起ui评审会议,然后一番友好交流后,达成一致;
  4. 后端同学进行接口定义并产出接口文档,然后和开发人员(前端、测试)进行接口评审
  5. 开发在一切确定后,产出自己的技术开发文档(一般是技术方案之类的)并最终进入开发。
  6. 一般开发同学,会在ui评审后,进行大概项目估时,并在接口评审后,给出最精准的估时!
  7. 开发中,到开发快结束时,测试同学发起测试用例评审,提出本次的冒烟用例(开发人员自测,通过后才能提测)和测试用例
  8. 开发完成后,进入测试阶段,测试通过后,良辰吉日上线。
  9. 上线后,产品验收,测试线上验证。

我在公司开发一个项目会经历什么

代码环境

开发会在开发环境进行开发自测,自测通过后,才会发布到测试环境,然后进入测试环节。测试环境没问题后。测试没有问题后,会路演并进入到预发环境进行上线前最后一次测试,一切顺利后最终上线。

我在公司开发一个项目会经历什么

代码仓库开发规范

1. 分支创建

一般情况下,基于master分支,创建本次项目的开发主分支feature/Epic-PRJxxx / feature/PRJxxx。 然后本次项目开发都会基于该开发主分支进行需求分支创建。

2. 代码合并

如果是小的需求合并,我们会合并到开发者分支中,在提交时,本人不允许进行代码合并,而是要通过mr(merge request)寻找本次一起开发的小伙伴或其他同学进行审核,并且在一系列的GitLab任务都通过之后,才能合并到开发主分支,如果有任何一个环节失败,要重新修改,到通过为止。

如果是开发主分支合并到master中,这时候说明项目要上线了。

如果是当天只有一个项目上线,则就直接reabse主分之后,向有权限的人(一般是项目负责人)发起mr,在代码审核人通过并GitLab相关流程跑通之后,就可以合并到master了。

如果当前有多个项目要上线,则需要创建一个release分支,将前面提到的开发主分支都合并到该分支上,然后最终将开发主分支合并到master

需要注意一点,从开发主分支,发起的合并请求,都需要stash起来,保留一个统一的提交。

3. 代码规范

日常开发中,项目中配置了EsLintPrettier等代码格式化和检测插件,并在代码提交前,依托于huskycommitlint进行代码提交前的最后一次检查,并检查提交信息是否合法,不合法,无法提交代码;代码不符合规范,会格式化后自动提交

4. 代码仓库开发规范小总结

master永远是最重要的,不允许一切危险操作,且有权限保护;

feature/Epic开发主分支,是当前项目中最重要的项目,等同于本次项目开发的master

release分支,用于多个项目同时上线时,才需要被创建,等同于多个上线项目的master

提交代码不允许自己合并,需要mr;

分支命名和提交信息要符合commitlint,要有意义。

关于一些git的操作,可以看下日常开发中,我是如何使用git的

总结

前面说的是我一直在公司遵守的一套项目操作流程。在我的印象中,凡是能够遵守这套的操作流程的项目,一般都没有什么问题,就是欢天喜地的上线了。但生活中处处充满惊喜,总有意外,有时候确实有些场景会被忽略掉,但总得来说,公司的项目开发流程一直在按照这套规则走下去。

如果你有更好的见解,欢迎一起交流,碰撞💥!!!

转载自:https://juejin.cn/post/7146149589857337381
评论
请登录