前端项目开发规范

LutherLiu
163 阅读2分钟

一. 开发分支分类

dev（开发）

release（测试）

uat（预发）--目前没有

master（生产）

二. 开发主体流程

  1. 需求评审

  2. 系分评审

    1. 前后端实际开发人员参与需求评审
    2. 前后端产出系分文档，对于需求的理解跟产品和业务同步
    3. 前后端设计对齐，产出文档，前端根据后端API文档进行交互设计和开发

  3. 开发排期

    1. 前后端明确人力，确定具体负责人
    2. 确定大致开发节奏，保持节奏同步

  4. 编码开发

  5. 开发自测联调

    1. 前后端明确联调节点
    2. 及时同步变更，同步业务和产品

  6. 自测通过，提交测试，合并代码到测试分支，部署测试环境

  7. 测试环境测试，开发修 bug

  8. 测试完成，提交预发，合并代码到预发分支，部署预发环境

  9. 预发环境做好数据隔离，接入正式数据测试，开发修 bug

  10. 测试完成，产品UI验收，开发根据验收文档变更

  11. 验收完成，提交生产，合并代码到生产分支，部署生产环境

  12. 生产运营（客户）验收，测试线上回归

  13. 验收完成，结项

  14. 线上问题回归，提出新的需求变更

三、开发代码管理

拉取代码

// 首次
git clone https://code.xxx.com/xxx/xxx.git
// 每次变更都需要重新切到master/预发布分支    拉取代码后再创建开发分支
git checkout master 
git pull

开发分支创建

git chekcout -b {功能类型}/{开发人员}-{环境}-{功能名称}
// 比如  git checkout -b feat/lccp-sea-downpage

// 按照这些命名规则 可以快速定位迭代的类型

 - feat：新功能

  - fix：修补bug

  - doc：文档

  - refactor：重构（即不是新增功能，也不是修改bug的代码变动）

  - test：测试

  - chore：构建过程或辅助工具的变动

代码变更

git pull   解决冲突
git add .
git commit -m'提交类型-提交内容'   比如  git commit -m'fix-ui'
git push

Push release分支提测

// 开发分支merge master
    git merge origin master  解决冲突   
  
    if(不存在release ){
    // 切到master 创建 
        git checkout master 
        git checkout -b release/{功能类型}-{环境}-{功能名称}
        git merge 开发分支
        git push 
    }else{
        git checkout release/{功能类型}-{环境}-{功能名称}
        git merge 开发分支
        git push 
    }

发布预发和线上环境

代码在开发分支变更，提交代码后，需要走merge request + code review 的过程，组内成员互相review，提出的建议及时处理，同时需要同步给测试同学和产品业务

avatar
文章
阅读
粉丝