这是学习笔记的第 2071 篇文章

  今天整理了下关于自动化上线的变更部分的内容，基本把字段和索引的变更范围涵盖了。

  首先明确下我们自动化上线做什么不做什么， 功能上是尽可能覆盖日常的变更操作，比在SQL质量满足的前提下进行自动化发布，而对于alter变更来说，因为缺少上下文信息，其实从审核层面很难做出太多的选择，所以在这种情况下最好的审核就是没有审核，而这个过程的可控性就是通过平台化操作完成的，即SQL是平台自动生成的。

   自动化上线不做什么，其实是我们更需要明确的，不光为了效率和便捷，更多是要考虑安全和影响范围，所以对于drop类操作统统杜绝，比如alter table drop column这种操作或者是alter table drop key这种操作。

对表结构进行变更的一个实现页面如下，我们可以输入表名，拉取到完整的字段列表。

然后在这种交互页面中进行编辑，点击即可生成完整的alter语句，支持多个字段的变更，也包含已有字段的修改（alter table modify column）等。

这个是半年前就实现的功能，而对于索引的部分也算是卷土重来，我们需要相似的设计思路，即得到索引的列表，然后通过平台化页面进行索引的创建。

从目前的情况来看，这基本能够涵盖80%以上的对象变更类操作。

而对于操作的风险等级，我们需要参考相关的数据情况和结构情况进行评估。

这些内容其实通过前后端集成都能够做差不多，而这些事情的本质是我们需要深思的，我觉得其中一个重要的支撑就是数据生命周期管理，有了这一层的保护机制，我们就可以复用很多表的元数据信息，把它编织成一张网，让数据流动起来，也能够使得数据的提取不需要做实时操作，而转为缓存级别的操作。

  要想把自动化上线做得足够细致可控，那么生命周期管理就是需要重视起来的一个方向。