根据Django的MVC架构特性，一般而言我们在本地开发时，当涉及到数据模型，步骤如下：
- 配置数据库信息；
- 定义/修改模型类（一个模型类对应数据库中的一张表）
当我们定义好模型时，数据库中并没有表，接下来我们需要进行迁移； - 执行命令，生成对应的迁移文件；
- 执行迁移，生成/修改对应的数据表；
可以看到，在命令的执行层面分成两步：
第一步，执行makemigrations命令，我们可以简单理解为记录当前app的模型变化信息；
第二步，执行migrate命令，这里我们可以简单理解为将对应的迁移文件解析成SQL并直接到连接的数据库中执行；
通过这套步骤，Django可以很方便的进行模块数据模型的变化记录、修改数据库信息。
云服务背景下的不同之处在本地环境中，上述步骤是很自然、没有问题的，但是来到云服务的环境中就有一些问题：服务使用的是RDS，有着严格的权限管控，所有的SQL执行均需要通过运维系统提交、检测、审批，这样Django的migrate命令就无法执行了。
此时，我们在第二步需要改用sqlmigrate命令：这个命令并不会直接去执行SQL，而是根据对应的迁移文件生成对应的SQL命令，在获取到这样的命令后，我们再到对应的IT平台提交执行即可。
不过，这里又有一个问题。
Django的模型迁移、SQL执行与服务启动是按顺序一气呵成的，中间并没有什么断点。
但是到云服务场景下就不同了：服务的升级部署、SQL的执行是分开的，这就造成如果服务服务先行升级部署，但SQL未执行，或者SQL先执行但服务未升级部署仍使用老模型与迁移文件，都有可能造成问题，当然，这也需要分开进行讨论。
1、新增表
对于这类，新增的数据表并不会对已有的部署代码造成什么困扰，因此可以在新代码部署之前就执行SQL。
2、新增字段
新增字段类似于新增表，但是也有不同之处：
- 如果新增的字段是有默认值、并且支持为空的，那么在新代码部署之前，老代码在新增数据时数据库会自动给新字段赋值，因此也不会造成什么影响。
- 如果新增的字段并没有默认值，也不许为空，那么老代码如果创建数据时，数据库层面自然就会报错了，因此这时我们需要等到服务部署完成之后才能执行SQL。
3、修改/删除字段
这种情况就没啥好讨论的了，为了避免出现问题，SQL要在部署完成后执行，并且二者时间间隔尽量的短。
