# 前言

通过前 2 章的内容，此时应该已经顺利的搭建了开发环境，也熟悉了服务器、shell 脚本的一些基本知识。

通常开发项目之前，一般都会有 Prd（项目需求文档），会详细介绍项目中的需求模块、功能设计等各种细节内容，避免开发中出现缺陷，后期迭代或拓展困难。

所以本章将会对整个项目进行需求分析与拆解，阅读本章你将会对工程化有进一步的了解，包括流程定制、Git Flew、权限设计、数据库建表等等。

# 项目分析

整个项目将分为 4 个学习模块，分别是：

服务端
客户端
CI/CD
监控

# 大纲设计

搭建一整套开发-测试-构建-部署的流程 --> 规范化流程
研发流程中加入能效概念（研发时间-测试时间-总体交付时间-bug 率及修复时间），作为项目提效的一个参考标准（影响因素太多，仅供参考） --> 流程闭环质量
合理的提测卡点，减少无效的提测，减轻测试负担 --> 简化交付成本
提供线上监控，分析每个版本使用率，报错率 --> 项目质量
提供快速回滚指定版本功能，确保新版本崩溃情况下能够快速恢复服务 --> 线上稳定性

# DevOps 设计

在小册大纲中，附图是一个较为完整的 DevOps 的项目架构设计，但作为一个实战的项目练习，个人独立完成所有的流程显然是比较困难。

下图是简单版本的流程架构，整个项目将依照下图的简版流程进行开发。

# 分析与拆解

根据流程图可以简单将 Node 模块分为 4 个部分

用户模块
- 项目注册用户
- GitLab 授权第三方注册用户
角色模块
- 管理员
- 测试
- 开发
项目管理
- 项目（增删改查一套）
- 打通 GitLab，通过 Open Api 关联项目并进行管理
- 创建任务流，对整个项目进行追踪管理
- CICD 项目构建部分
线上监控（方案暂定）

后续将按照上述 4 个模块逐步开发，具体的细节部分会在每个模块开发中介绍。

GitLab 除了是一款优秀的代码仓库管理平台之外，本身也具备当一个小型项目管理系统的潜质，包含的项目、团队、权限、用户、issue 等等功能都已经非常完善。后续的工程将会非常依赖 GitLab，对 GitLab 提供的开放功能进行深度拓展，定制出合适的工程化体系。

# 流程设计

如上图所示，将上述的发布流程更进一步的细化可以分为下面 4 类：

单项目发布流程（一个需求只需要一个工程完成）
生产环境出问题，快速回滚功能
集成项目发布流程（一个需求可能会有多个工程参与开发、发布）
Bug 修复发布流程（无需求，需要快速修复线上已知但不紧急 bug 的发布流程）

任务流的设计其实非常复杂，为了加快交付第一版，先将任务流固定为以上 4 类，可以减少开发量与难度，后期可以添加或者修改某个流程。

# Git Flow 流程

Git Flow 的核心是通过在项目的不同阶段对 branch 的不同操作包括但不限于 create、marge、rebase 等来实现一个完整的高效率的工作流程。在项目的质量把控、多人协作中有非常好的实践。

Production 分支

就是常用的 Master 分支，这个分支包含最近发布到生产环境的代码，最近发布的 Release，这个分支只能从其他分支合并，不能在这个分支直接修改。

Develop 分支

这个分支是的主开发分支，包含所有要发布到下一个 Release 的代码，这个主要合并于其他分支，比如 Feature 分支。

Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，合并回 Develop 分支，并进入下一个 Release。

Release 分支

当需要发布一个新 Release 的时候，基于 Develop 分支创建一个 Release 分支，完成 Release 后，合并到 Master 和 Develop 分支。

Hotfix 分支

当在 Production 发现新的 Bug 时候，需要创建一个 Hotfix 分支, 完成修复后，合并回 Master 和 Develop 分支，所以 Hotfix 的改动会进入下一个 Release。

整体的分支管理流程如下图所示

# 项目自建流程

Git Flow 的优点非常明显，但在实际操作中，不能避免很多流程会有人工介入，有些环节不能完全约束与加入，所以在 Git Flow 的基础上再创建项目的自建流程，将 branch 与自建流程关联，可以对项目中的开发节点、发布节点、测试以及监控等流程与功能进行追踪。

如图每个工程都共享一个 Version 版本号，分支创建分为版本升级、特性更新、修订补丁三种模式，强制项目所有分支创建的命名规则都会升级，不会出现重复跟降级。

上述流程的优点：

工程使用固定的版本锁死，版本对应需求流程，上线质量得到保障
每个开发分支都只能部署到测试环境，必须合并到对应的版本分支之后才能上生产
所有合并到 master 或者 relase 分支会被删除，防止一条分支处理过多业务，后期 review、回滚难度提升
realse 版本分支上线之后，生成对应 tag
hotfix 版本可以从对应的 tag 拉出，可以明确的知道 hotfix 具体修复的是哪个版本的问题

上述流程的缺点：

固化版本流程导致创建命名规则固定，且版本号不能升级只能降级
流程限制，降低开发灵活性

没有完美的解决方法，所有 devops 流程都要结合真实项目需求来设计，上述也仅是其中一种解决方案

# 用户、权限系统设计

# 用户、权限方案

比较通用的用户信息表如下所示：

用户表（user）：记录用户基本信息，不限于密码、用户名等
权限表（permission）：记录权限信息，例如增删改查各种权限
角色表（role）：记录角色信息，例如开发、测试、产品等各种角色
用户 — 角色表（user_role）：记录用户与角色关系表，有一对多的关系
角色 — 权限表（role_permission）：记录角色与权限的管理，有多对多的关系

更加复杂的用户权限设计可以加入用户组的概念，用户组级别的权限管理。

如果全部都从头开发的话，估计直接劝退绝大部分的人了，整个项目的工程量会非常大，快速搭建一个可用的系统并不是一定要自己做完所有的事情，可以选择跟第三方系统对接。

# 第三方用户授权

钉钉企业用户
企业微信用户
GitLab 用户关（后面会具体介绍）
现在有内部系统提供用户与权限接口（对接企业自身内部系统）

以上可以互相搭配使用，比如内部用户系统接了钉钉或者企业微信的用户模块，然后通过邮箱关联一个 GitLab 账号，还是比较常见的做法。

其实 GitLab 本身对于项目级别有了非常细致的权限管理，作为实战项目，可以简化用户系统，直接使用 GitLab 的用户、权限体系作为源数据。具体的流程可以参考下面的时序图

# GitLab 权限

通过 GitLab Api 获取项目信息的同时也能拿到该用户在对应项目中的 permissions，可以依赖 GitLab 自身对项目、团队做的权限做一个项目权限映射，极大的节约项目的开发时间与成本。

GitLab 权限	GitLab 权限描述	access_level	映射项目角色	对应项目角色描述
No access	啥都不能干	0	无任何权限	啥都不能干
Guest	创建issue、发表评论，不能读写版本库	10	项目经理	可以查看项目进度
Reporter	克隆代码，不能提交	20	测试	项目测试、提交 bug
Developer	克隆代码、开发、提交、push 等	30	开发	项目开发，发布测试、预发环境
Maintainer	创建项目、添加tag、保护分支、添加项目成员、编辑项目等	40	管理者	项目管理，发布生产环境
Owner (Only valid to set for groups)	设置项目访问权限、删除项目、迁移项目、管理组成员等	50	最高权限管理者	啥都能干

# 数据库设计

# 设计用户表

正常来说，第三方用户设计会有 3 张:

表名	描述
user	系统用户表
social_account	第三方用户表
user_social_account	系统与第三方用户关联表

但根据上面的用户权限设计方案，GitLab 将作为底层数据来源，所以项目的 user 表可以直接跟 GitLab 的 social_account 表合并成为一章，包括用户 id 都可以直接使用 GitLab 的信息，保存一些常规不变的数据，可能会改变的数据可以直接从 GitLab 获取然后合并返回给业务即可。

这只是为了项目开发的速度而做的变通，实际情况中要根据自己的业务来设计用户表，自建用户的话，可以赋予更多自由度定制与功能拓展。

# 设计业务表

根据上述的需求分析，先将最复杂的 project 与 branch 表结构设计出来，方便后期使用。

将 GitLab Project 与 Branch 字段与需要的数据落库到本地，再根据项目需求新增字段，大概的表结构如上图所示

结合上述项目流程设计，说明一下表结构关系：

工程表 project 会管理多个分支 branch，可以查询当前工程下所有分支的状态（是否被提测，是否存在流程中）
创建一个流程（等同于需求）关联多个 branch 开发
流程创建完之后必走完所有步骤直至完结（开发-测试-预发-生产）
当 branch 被一个流程关联之后，既被所锁定，不会再次被加入到其他流程（需求锁定隔离，保证开发过程不会有干扰）
在流程的提测步骤中，可以针对不同 branch 进行多次提测（复杂需求通过分批提测，完成预期目标）
当流程中所有 branch 的状态都已测试通过之后，该流程状态才进入下一个阶段，否则一直停留在测试阶段

这里先简单介绍比较复杂的表结构，后续在开发过程中，会逐步介绍其他的表结构与设计。

# 本章小结

本章是针对于整个项目的需求分析与设计，为了减少成本与时间，整个工程将依赖 GitLab 去开发。

从下一章节开始，将正式进入 Node 项目的开发。

设计篇 项目分析与设计|Node Devops专题

设计篇 项目分析与设计|Node Devops专题

设计篇项目分析与设计|Node Devops专题

设计篇项目分析与设计|Node Devops专题