kingyingliang

git

2018-11-19 git

分支策略

开发环境的区别，我们如何称呼

  • dev: 开发中使用的环境，可用来进行联调和自测
  • site: 前后端联调 / 自测完成，给到测试人员测试的环境
  • uat: 测试人员功能测试通过，在此环境使用模拟正式数据测试
  • test: 测试人员对功能进行测试，包含 site & test 行为
  • prd: 预生产 / 灰度测试，数据和环境完全和正式环境一样，用户看不到的生产环境

开发者开发拉分支流程

分支名称 说明 特性 步骤 自动部署 备注
release 预发布分支 - 测试版本(test) 无法 Push , 需透过 GitLab 上的 merge request 功能。 修复紧急 bug 时，允许 Push 方式 1.接到 merge request 时，资深工程师负责进行 peer review (需要提交 merge request 时指定一位 peer review 人员)。2.peer review 通过后，认同提交3.若为修复 bug，直接 Push 1.MR 通过，部属预发布或测试机器.2.紧急修复 bug 时，Push 后，部属预发布或测试机器 1.完成阶段性功能时，从 develop 分支拉出 release 分支，供上线前测试2.预发布环境，同正式机器，亦可当成测试机
master 主分支 - 生产正式版本(prd) 1. 无法 Push , 需透过 GitLab 上的 merge request 功能 1. merge request 时，需进行code review (技术 leader )2.code review 审核通过后，同意 merge request 提交（由 PM 同意，表示负责） MR 通过，部属正式线上机器 拉其他分之前，在 master 建立完整的环境
hotfix-* 修复 master (线上)或 release (测试)发现之 bug 安装 lint-staged ＆ husky 插件，本地提交时会对 code 进行静态扫描。不通过则无法提交 1.发现 bug ，从 master 或 release 拉出分支，命名 hotfix-* (* 为 bug 提交系统上的 bug 号)2.修复后，直接 Push 至 release 分支3.测试人员确认无误，采 GitLab 上的 merge request 合并至 master 分支，自动部属至线上4.打上 tag5.Cherry Pick 到 develop 分支6.删除该 hotfix-* 1.Push 至 release 分支时，会自动部属至测试机2.MR 通过后，自动部署线上 1.修复后，合并后删除2.原则上一个 bug 建一次分支一次 push
develop-* 功能开发所进行分支 1. 安装 lint-staged ＆ husky 插件，本地提交时会对 code 进行静态扫描。不通过则无法提交。2.不需 Push 至 Gitlab，本地开发 1.从 develop 分支上拉出 develop-。2.开发完成后，自检程式码。3.无误后合并进 develop 分支。4.功能验证无误后，删除 develop- 分支 1.一个模块功能一个分支。2.功能分支在合并确认无误后删除
develop 常驻开发主分支(dev) Push 至 develop 分支，会跑单元测试或 BDD 测试，覆盖率未达标时，无法推至 develop 若为第三方合作项目，需在 Push 到 Gitlab 时进行 peer review，确保上 GitLab 的 code 是正确的 Push 至 develop 时，自动部属开发机(dev)

拉分支流程

  1. 初始仅 master 主分支，建置初始环境。( sprint 0 )
  2. 进入开发时，从 master 主分支拉出 develop 分支 ( sprint 1 )
  3. 开发者从 develop 分支再拉出功能分支 (develop-*)
  4. 开发者在本地端编辑器安装 ESLint 插件 协助开发时自检程式码是否合乎规范
  5. 开发者本地 commit 时，因安装 lint-staged ＆ husky 插件，所以每次 commit 推至 GitLab 时，皆会进行语法错误自检
  6. 开发者将程式码推到 GitLab 时会与 develop 分支做预合并(透过 gitlab 上的 smart merge 功能)，检查该开发分支、同期其他开发者分支 (develop-*) 与 develop 分支的冲突，确保提交到 gitlab 是无冲突的，有冲突会即时 mail 反馈
  7. 每个 sprint 完成该功能后，功能分支(develop-*)合并进 develop ，
  8. Push 至 develop 分支时，会进行覆盖率检测，答标后，自动发布到内网开发环境，预定的检查者也会对功能进行 peer review 。
  9. 功能无误后，开发删除该功能分支
  10. 从步骤 2 开始新的循环，直到阶段性功能开发完成
  11. 从当前 master 分支拉出 release 分支，在 Gitlab develop 分支上对 release 分支发 merge request 请求，同意后自动部属测试机
  12. 供测试人员进行 QA ，若有 bug，从当前 release 分支拉出 hotfix-* 分支进行修正，修正完后直接并入release 分支且 cherry pick 进 develop 分支，删除 hotfix-* 分支
  13. 测试人员对 release 分支版本确认无误后，从 gitlab 上发 merge request，由 owner 进行审核，无误后并入 Master ，并打上 tag，同时删除 release 分支。此时部属至正式环境
  14. 阶段性开发结束后,删除 develop 分支，届时仅存 Master 主分支。
  15. 若线上发现 bug，从 master 拉出 hotfix-* 分支进行修正，(此时会手动部属至测试环境供测试人员确认)，无误后并入 master 分支并删除该 hotfix-* 分支，打上 tag
  1. 分支命名支援小写字母、数字、连字符、下滑线等四种
  2. 新功能开发请从 develop 拉取分支，命名为 develop- + 功能模块英文名称
  3. release 分支为 develop 分支达到该 sprint 里可交付版本时拉出的分支，供预发布用，预发布结束以后，必须合并进 develop 和 master 分支。
  4. hotfix 分支为 master 分支(线上)或 release 分支出现问题时，拉出分支修改后并回。 命名为 hotfix- + #+bug 标号
develop-login
hotfix-#123456
1
2

预发布期间，develop ＆ develop-* 分支持续开发，release 分支发现问题时，直接拉 hotfix-* 分支修复，，若判断为重大 bug ，需要记录以供日后追踪，修复后 ，在 GitLab 上发 merge request 并入 master 或 release 分支

打 Tag 的规则

  1. 三个数字且以 . 为分隔构成，由 0.0.1 开始
  2. 每次打上 Tag 需加入发布说明
  3. 三位数字代表意义分别为大版本迭代 . 一般迭代 . bug 修复或补丁
  4. 第一个为主版本号,第二个为子版本号,第三个为阶段版本号
    主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
    子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改
    阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
  5. 版本+1 时，后面若有其他数字则归零，如 v1.20.3 => v2.0.0 , v4.5.6 => v4.6.0
  6. 如果线上发布的版本（例如 v1.0）发现 Bug，需要修复，那么基于之前的 Tag 创建一个分支（例如 hotfix-v1.0-xxx）出去，在分支上修复，然后提交 PR，代码审查和自动化测试通过后，从分支上创建一个新的 Tag （例如 v1.0.1）
  7. 经常性打补丁，可以创建一个发布版本的分支，例如 release-v1.0，每次打补丁，都直接从发布分支 release-v1.0 而不是 master 创建新的分支（例如 hotfix-release-v1.0-xxx），修复后提交 PR，代码审查和自动化测试通过后，合并回分支 release-v1.0，然后基于 release-v1.0 分支发布补丁。

提交规范

GIT.png

Commit message 包括 Header，Body 和 Footer 三个部分。 Header 是必需的，Body 和 Footer 可以省略。

Commit message 格式

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
格式

<type>(<scope>): <subject>
fix(home.vue): 修正页面 name 变数字串首字母大写问题。
 
// type 字串皆小写
// () 和 : 皆为半角
// : 后面与 subject 有一个半角空格
1
2
3
4
5
6
type
  • feat: 新功能（feature）
  • fix: 修补 bug
  • docs: 文档（documentation）新增文件
  • style: 格式样式（不影响代码运行的变动）
  • refactor: 重构（即不是新增功能，也不是修改 bug 的代码变动）
  • test: 增加测试
  • chore: 构建过程或辅助工具的变动
  • modify: 程式码的调整
  • revert: 撤销以前的 commit (后面跟着被撤销 Commit 的 Header)
revert: feat(pencil): add 'graphiteWidth' option
1

完整格式

<type>(<scope>): <subject>
<---空行--->
<body>
<---空行--->
<footer>
1
2
3
4
5

范例

// 范例1
modify(login.vue): 修改灯区块显示文字部分
 
 
// 范例2
fix: 修正 jenkinsfile 内容多馀字串导致集成执行错误问题
 
 
// 范例3 加入 body
style(main.css): 登入页面样式
<---空行--->
登入页面异动下面两个样式
- 登入按钮样式
- 帐和输入区块延长至 200 px
 
 
// 范例4 加入 body footer
fix(login): 修正登入区块帐号可输入特殊符号问题
<---空行--->
登入区块帐号输入滤掉特殊符号
<---空行--->
Close #9654
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
特殊情况

Revert

revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
1
2

commit

Commitizen: 替代你的 git commit

全局安装
npm install -g commitizen cz-conventional-changelog
echo'{ "path": "cz-conventional-changelog" }' > ~/.czrc
1
2

主要, 全局模式下, 需要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter.

项目级安装
npm install -D commitizen cz-conventional-changelog
1

package.json中配置:

"script":{...,"commit":"git-cz",},"config":{"commitizen":{"path":"node_modules/cz-conventional-changelog"}}
1

如果全局安装过 commitizen, 那么在对应的项目中执行 git cz or npm run commit 都可以.

Commitlint: 校验你的 message

commitlint: 可以帮助我们 lint commit messages, 如果我们提交的不符合指向的规范, 直接拒绝提交, 比较狠.
同样的, 它也需要一份校验的配置, 这里推荐 @commitlint/config-conventional (符合 Angular团队规范).
安装:

npm i -D @commitlint/config-conventional @commitlint/cli
1

同时需要在项目目录下创建配置文件 .commitlintrc.js, 写入:

module.exports={extends:['@commitlint/config-conventional'],rules:{}};
1

结合 Husky

校验 commit message 的最佳方式是结合 git hook, 所以需要配合 Husky.

npm i husky
1

package.json 中添加:

"husky":{"hooks":{...,"commit-msg":"commitlint -e $GIT_PARAMS"}},
1

standard-version: 自动生成 CHANGELOG

通过以上工具的帮助, 我们的工程 commit message 应该是符合 Angular团队那套, 这样也便于我们借助 standard-version 这样的工具, 自动生成 CHANGELOG, 甚至是 语义化的版本号(Semantic Version).

npm i -S standard-version
1

package.json 配置:

"scirpt":{...,"release":"standard-version"}
1

GitLab Merge Requests

Merge Request（MR，合并请求）是作为编码协作及版本控制平台的 GitLab 的基础功能。就和它的命名一样：是一个将一个分支合并到另一个分支上的请求
当完成 develop-* 分支的开发，并进行了自测，想要向主干分支 develop 合并时，通过登录 GitLab 提出 MR。

Peer Review

开发的前两次 sprint 由欣和方进行 peer peview ，开发流程成熟后，未来由第三方每个开发指定另一位开发进行 peer peview，同时为避免因频繁进行 peer peview 而降低开发效率，现阶段仅在 develop-* 分支合并 develop 分支时进行 MR ，在 release 分支进行 bug 修复以及 develop 分支上进行非常小粒度的开发时不需要提 MR，重要功能一定要提 MR。
Review 内容涉及编码规范（命名、注释、文件目录组织结构等）及最佳实践，在编码规范及需要小范围改动的最佳实践修复后进行分支的实际合并。对于改动较大且影响范围较低的代码，可以安排在 Debug 阶段或版本末期进行重构。 提交格式

标题：develop-* 新合并请求
描述：
 
develop-* xxx 功能合并请求
<空行>
<实现功能点，改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。>
1.
2.
3.
4.
 
指派给：欣和 code prview 负责人或既定开发者
来源分支：develop-*
目标分支：develop
 
[]接受合并请求后删除来源分支。->暂时不勾选，开发手动删除
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

在创建 MR 时，Reviewers（审核人）一栏里主要填写“必需审核人”。只有这些人审核都通过，才允许合并。
选择审核人需留意，关注的视角不太一样。团队 Leader 关注你是否完成了任务，前后端架构师关注是否符合公司统一的架构、风格、质量，产品架构师从整个产品层面来关注这个 MR

进入 gitlab 页面，选择欲合并的项目

GIT.png

在欲合并的分支点击右边 [合并请求] 按钮
输入表单讯息 （描述,指派给 kingyinliang , 目标分支）后送出

GIT.png

git 工作流

Git 三大特色，分支，暂存区，工作流

何谓工作流

WorkFlow 的字面意思，工作流，即工作流程。因为有分支的存在，才构成了多工作流的特色。事实的确如此，因为项目开发中，多人协作，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起，而且真实项目中涉及到很多问题，例如版本迭代，版本发布，bug 修复等，为了更好的管理代码，需要制定一个工作流程，这就是我们说的工作流，也有人叫它分支管理策略。
工作流不涉及任何命令，因为它就是一个规则，完全由开发者自定义，并且自遵守，正所谓无规矩不成方圆，就是这个道理。

常用工作流

目前使用度最高的工作流前三名分别是以下三种：

其中 Git Flow 出现的最早，GitHub Flow 在 Git Flow 的基础上，做了一些优化，适用于持续版本的发布，而 GitLab Flow 出现的时间比较晚，所以综合前面两种工作流的优点，制定而成的一个工作流。

bug(缺陷)提交原则

为什么我们要有 bug 提交原则，比如，当你发现了一个菜单栏上某个条目缺失的问题，在递交缺陷报告前，通常会去缺陷管理系统搜索一下是否已经有人递交过类似的缺陷。
所以，如果缺陷标题本身就能概括性地描述具体问题，你就可以通过阅读标题判断类似的缺陷是否被提交过，大大提高测试工程师提交缺陷报告的效率。 最近在了解测试，刚好看到一些问题的提交原则，顺手整理一下讯息。JIRA 上已有递交 bug 的完善流程，这里也针对各信息提供细节说明。
具体描述”什么问题”，同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。

缺陷标题

  1. 标题应该尽可能描述问题本质，而避免只停留在问题的表面。
  2. 比如，
    “商品金额输入框，可以输入英文字母和其他字符” // bad
    “商品金额输入框，没有对输入内容做校验” // nice

缺陷概述

缺陷概述的目的是，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。

缺陷影响

缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。
严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。

  1. 缺陷越严重，优先级就越高；
  2. 缺陷影响的范围越大，优先级也会越高；
  3. 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
  4. 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。

严重程度（Severity）

  1. Blocker: 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
  • 严重花屏
  • 内存泄漏
  • 用户数据丢失或破坏
  • 系统崩溃/死机/冻结
  • 模块无法启动或异常退出
  • 严重的数值计算错误
  • 功能设计与需求严重不符
  • 其它导致无法测试的错误, 如服务器500错误
  1. Critical：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
  • 功能未实现
  • 功能错误
  • 系统刷新错误
  • 数据通讯错误
  • 轻微的数值计算错误
  • 影响功能及界面的错误字或拼写错误
  • 安全性问题
  1. Major：即界面、性能缺陷、兼容性。
  • 操作界面错误（包括数据窗口内列名定义、含义是否一致）
  • 边界条件下错误
  • 提示信息错误（包括未给出信息、信息提示错误等）
  • 长时间操作无进度提示
  • 系统未优化（性能问题）
  • 光标跳转设置不好，鼠标（光标）定位错误
  • 兼容性问题
  1. Minor/Trivial:即易用性及建议性问题。
  • 界面格式等不规范
  • 辅助说明描述不清楚
  • 操作时未给用户提示
  • 可输入区域和只读区域没有明显的区分标志
  • 个别不影响产品理解的错别字
  • 文字排列不整齐等一些小问题

缺陷的优先级（Priority）

  1. P0- Immediate
    即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
  2. P1- Urgent
    即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
  3. P2- High
    即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
  4. P3- Normal
    即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
  5. P4- Low
    即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

环境配置

重现缺陷的环境配置细节。

前置条件

测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。
比如，某个业务操作需要先完成用户登录，你在缺陷重现步骤里就没有必要描述登录操作的步骤细节，可以直接使用 “前置条件：用户已完成登录”的描述方式；

缺陷重现步骤

缺陷重现步骤是整个缺陷报告中最核心的内容，通常是从用户角度出发来描述，每个步骤都应该是可操作并且是连贯的，其目的在于用简洁向开发工程师展示缺陷重现的具体操作步骤。

期望结果和实际结果

期待结果来自于对需求的理解，而实际结果来自于测试执行的结果。需要说明应该发生什么，而不是什么不应该发生。

变通方案

提供一种临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者他们一同决定。变通方案和优先级相关。

根原因分析（Root Cause Analysis）

RCA，在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，提升修复效率。

附件

界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等证据支持。

范例

(待补)

Last Updated: 2019-8-14 6:29:41 PM

← 测试策略 →