通过CI/CD集成，对持续集成的代码做SQL审核

[winfredLIN]

需求描述（Describe）

背景：用户A希望在现有GOCD流水线中加一个审核节点，引入SQLE的审核能力，对变更脚本中的SQL做审核，拦截不合规的SQL

实现方案

用户使用

权限
用户需要对本项目数据源有配置流水线的权限才能够为本项目的数据源配置流水线
需求：1 在项目中 2 拥有配置流水线权限（细粒度：数据源）

创建与更新流水线
用户可以创建和更新流水线，在流水线中创建和更新流水线节点，流水线节点可以改变顺序

配置流水线
用户创建好流水线节点后，可以复制scannerd的启动命令，以配置流水线

方案实现

数据表设计
目前将流水线和流水线节点分为两张表，一条流水线对应多个节点，业务上一个流水线节点对应一个启动命令

type Pipeline struct {
	Model
	ProjectUid  ProjectUID `gorm:"index; not null" json:"project_uid"`     // 关联的流水线ID
	Name        string     `gorm:"type:varchar(255);not null" json:"name"` // 流水线名称
	Description string     `gorm:"type:varchar(512)" json:"description"`   // 流水线描述
	Address     string     `gorm:"type:varchar(255)" json:"address"`       // 关联流水线地址
}

type PipelineNode struct {
	gorm.Model
	PipelineID       uint   `gorm:"type:bigint;not null;index" json:"pipeline_id"`        // 关联的流水线ID
	UUID             string `gorm:"type:varchar(255);not null" json:"uuid"`               // 节点uuid
	Name             string `gorm:"type:varchar(255);not null" json:"name"`               // 节点名称
	NodeType         string `gorm:"type:varchar(20);not null" json:"node_type"`           // 节点类型
	NodeVersion      string `gorm:"type:varchar(255)" json:"node_version"`                // 节点版本
	InstanceName     string `gorm:"type:varchar(255)" json:"instance_name,omitempty"`     // 数据源名称，在线审核时必填
	InstanceType     string `gorm:"type:varchar(255)" json:"instance_type,omitempty"`     // 数据源类型，离线审核时必填
	ObjectPath       string `gorm:"type:varchar(512);not null" json:"object_path"`        // 审核脚本路径
	ObjectType       string `gorm:"type:varchar(20);not null" json:"object_type"`         // 审核对象类型
	AuditMethod      string `gorm:"type:varchar(20);not null" json:"audit_method"`        // 审核方式
	RuleTemplateName string `gorm:"type:varchar(255);not null" json:"rule_template_name"` // 审核规则模板
	Token            string `gorm:"type:varchar(512);not null" json:"token"`              // token
}

流水线节点更新逻辑

节点更新的逻辑有以下功能需求

1. 流水线节点更新一次，对用户来说视为一个版本，数据存储上需要能够方便筛选出每一个版本的所有节点【本次PR完成】
2. 流水线的每一个节点，会生成一段执行脚本的命令，当节点信息修改可以不影响脚本命令时，不应改变脚本命令【本次PR完成】
3. Scannerd在客户的流水线中执行，请求SQLE时携带的token需要能够唯一确定SQLE上的一个流水线节点【本次PR未完成】

• 本次PR先保存了流水线节点的版本和uuid（实际上不是唯一的，可以被继承，这个名称可能需要修改），在实现不改变执行命令的功能下，使得token可以唯一确定一个节点

节点更新时，遵循以下逻辑

1. 当用户没有修改会导致需要变更启动命令的配置时，节点version uuid token继承之前节点的数据
2. 当用户修改了节点配置，导致该节点要正确运行需要重新配置运行命令时，节点会使用新的version uuid token
   *在界面上的表示形态如下图所示：
3. uv1表示的是用户理解的版本1 user version 1
4. node1 表示用户理解的节点1，uuid表示节点的唯一id
5. n1-v1表示节点1的第一个版本 node 1 version 1
6. uv2表示用户理解的版本2，此时由于node1实际未修改，因此继承了之前节点的uuid version token，用户可以无需修改启动命令
7. 在用户修改的第三个版本中，即行uv3，节点1更新了参数(例如修改了审核路径，实际上用户也会知道需要修改命令)，导致需要修改启动命令，因此这里的version token都更新了

	版本
	↓
	+-------+-------+-------+-------+
	|       | node1 | node2 | node3 | <- 节点名称
	+-------+-------+-------+-------+
	|       | uuid1 | uuid2 | uuid3 | <- 此列不展示
	+-------+-------+-------+-------+
	|  uv1  | n1-v1 | n2-v1 |       |
	+-------+-------+-------+-------+
	|  uv2  | n1-v1 | n2-v2 |       |
	+-------+-------+-------+-------+
	|  uv3  | n1-v3 | n2-v2 |       |
	+-------+-------+-------+-------+
	|  uv4  | n1-v3 | n2-v2 | n3-v4 |
	+-------+-------+-------+-------+

升级方案

由于增加了权限，需要在数据库中将dms_config表的更新权限位置为一，然后重启dms，SQLE将会将新的权限配置项载入，

1. 权限位置为一执行以下SQL

update dms.dms_configs set need_init_op_permissions=1 where uid=700100;

2. 重启dms，执行以下命令即可

systemctl restart dms

变更影响面

新功能，不影响其他功能

受影响的模块或功能

外部引用的潜在问题或风险

版本兼容性

测试建议