这是学习笔记的第 2071 篇文章
今天整理了下关于自动化上线的变更部分的内容,基本把字段和索引的变更范围涵盖了。
首先明确下我们自动化上线做什么不做什么, 功能上是尽可能覆盖日常的变更操作,比在SQL质量满足的前提下进行自动化发布,而对于alter变更来说,因为缺少上下文信息,其实从审核层面很难做出太多的选择,所以在这种情况下最好的审核就是没有审核,而这个过程的可控性就是通过平台化操作完成的,即SQL是平台自动生成的。
自动化上线不做什么,其实是我们更需要明确的,不光为了效率和便捷,更多是要考虑安全和影响范围,所以对于drop类操作统统杜绝,比如alter table drop column这种操作或者是alter table drop key这种操作。
对表结构进行变更的一个实现页面如下,我们可以输入表名,拉取到完整的字段列表。
然后在这种交互页面中进行编辑,点击即可生成完整的alter语句,支持多个字段的变更,也包含已有字段的修改(alter table modify column)等。
这个是半年前就实现的功能,而对于索引的部分也算是卷土重来,我们需要相似的设计思路,即得到索引的列表,然后通过平台化页面进行索引的创建。
从目前的情况来看,这基本能够涵盖80%以上的对象变更类操作。
而对于操作的风险等级,我们需要参考相关的数据情况和结构情况进行评估。
这些内容其实通过前后端集成都能够做差不多,而这些事情的本质是我们需要深思的,我觉得其中一个重要的支撑就是数据生命周期管理,有了这一层的保护机制,我们就可以复用很多表的元数据信息,把它编织成一张网,让数据流动起来,也能够使得数据的提取不需要做实时操作,而转为缓存级别的操作。
要想把自动化上线做得足够细致可控,那么生命周期管理就是需要重视起来的一个方向。