公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。
几个场景如下
- 分表规则通过migrate?每天新增表跑你的 migrate?一定是dba做的。
- 还是分表,分表的数据表你migrate添加字段?索引?
- 归档表,单表3kw以上生产数据库你一个migrate就开始跑DDL了?
- 你一个migrate里一会儿addColumn,一会儿dropColumn,你猜dba会不会揍你(不骂,直接动手)
- 上线流程,先执行migrate还是先同步代码?
- 还是上线流程,有错误需要撤回当前版本,代码已经紧急撤回了你的migrate呢怎么回滚?
- 最后,还是上线流程,你们家dba允许开发染指数据库?
migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。
公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。
几个场景如下
- 分表规则通过migrate?每天新增表跑你的 migrate?一定是dba做的。
- 还是分表,分表的数据表你migrate添加字段?索引?
- 归档表,单表3kw以上生产数据库你一个migrate就开始跑DDL了?
- 你一个migrate里一会儿addColumn,一会儿dropColumn,你猜dba会不会揍你(不骂,直接动手)
- 上线流程,先执行migrate还是先同步代码?
- 还是上线流程,有错误需要撤回当前版本,代码已经紧急撤回了你的migrate呢怎么回滚?
- 最后,还是上线流程,你们家dba允许开发染指数据库?
migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。
我们也在用哈,可能是公司规模太小了,没有运维组,也没有 DBA。基本上几个骨干工程师都能兼任一部分,我收集并撰写迭代发布文档并负责发布上线。
其实还是跟各个团队的发布流程相关,肯定不是所有人都有生产环境账号的,有账号的人要分配权责,负责好自己承担的任务。
置于具体细节,是否可以执行回滚,那其实是发布细节的问题。一般是不执行回滚的,因为非常麻烦,需要制定相应的回滚方案。执行迁移也不都是随部署执行的,比如发布前需要搞清楚,新的代码是否兼容旧版本数据库结构,如果完全兼容便可放心的执行部署后迁移。否则,我们会先升级一个维护专用的 POD (我们这里用的k8s集群),在这个 POD 容器中执行迁移和其他需要在部署代码前完成的准备工作,然后在升级整个集群。
可能我水平不行吧,没去过什么大公司,干过两三家公司都没有专人维护数据库。 甚至 leader 也不太操心,我做的功能模块是怎么实现的,怎么样的表设计, 功能优化之后对数据表有没有修改。基本上如果我忘了数据表有过那些修改,没有人能替我想起来, 所以我用 migrate 。
而且我感觉 migrate 真的方便测试, 比如我本地开发好了,我测试环境一拉代码, php artisan migrate
就能进行测试了。如果测试环境没问题, 生产环境和测试环境都是同样的迁移文件必然也没问题。 如果没有 migrate, 除非我每次测试环境测试前,都从生产环境备份一个数据库下来,然后再运行这一次修改的SQL语句。 不然我就总疑心测试环境的数据库和线上环境的数据库到底一致不一致。
技术永远是为了业务服务的。单纯炫技没个鸟用。
想当年刚入职小公司,那是前后端一把搂,这时候别说你跑migrate,你直接在线上改,都没人管。老板只是一句话,好了没,能用了吗?上次说的功能开发完了 吗?
后续公司搞到钱了,各种人员都到位了。你还想一把搂?运维、DBA、测试、产品、那不上来一把搂你?
有钱大家一起赚,你都搞了。别人怎么活。哈哈!!!
最后:没人管你的时候,就证明这个可行。
现在我们流程:
1、项目中必须要写 migration 文件,便于接手者了解和上手。
2、相应的 SQL 改动在自动运维平台上提交工单、
3、必须3人审核,直属领导、技术二把手、DBA点确认后,自动执行。【其实真正起作用的是 自己和直属领导】
用吧 对自己方便点 其实很多程序员接触不到那么有规模的公司的 可能是我去的都比较low 都用migrate不用还要被说。而且都用rds,感觉没那么多问题。
再换句话说,真的有公司那么啰嗦的话,你也可以用啊,大不了转换城sql语句交给对方,migrate看起来还是要规范点的
公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。
几个场景如下
migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。