软件开发过程中发版本是怎么做到不遗漏的呢？
- 内容介绍
- 文章标签
- 相关推荐
公司规模稍微比较小，但是还是有10 来个开发，我们分支策略是生产分支拉功能分支，然后本地自测完合开发分支，提测再从功能分支合并测试分支，测试没问题再从功能分支合并合并预发布分支，最终没问题再直接从预发布合并到生产分支。在这个开发过程中会涉及到数据库sql，界面上参数配置等等，每次都会写发布文档，但是对于sql可能在开发过程中多次调整，导致有些环境是执行了部分 sql，每次整理 sql 都不知道对应环境执行到哪个位置了，目前也没有采用 flyway 这种自动管控，请教各位佬们做开发如何做到发版不遗漏的呢。
网友解答：--【壹】--：
flyway 以前公司有用过，如果是单人开发并且数据库比较单一的话还行，我们项目有很大的定制化以及国产化数据的东西，用自动管控同时连开发库没拉别人的代码连同一个数据库会存在奇奇怪怪的问题，你说的这个 excel 表我们目前有个在线文档就是这样做的，但是给到这个 sql 链接是仓库地址链接会存在变动的情况，有点刻舟求剑的感觉
--【贰】--：
1.理想情况就是文档记录都是跟着代码仓库同步走，作为一个团队很难每个人都有那么默契
2.flyway 这个以前公司用过，有利有弊一直没有上，也看过 mybatisplus 自带的 autoddl 功能。https://baomidou.com/guides/auto-ddl/
--【叁】--：
道理是这个道理，也不是开发扛下所有，只是想把自己端口的事做好，每次发大版本的时候很多特性分支导致sql混乱得很还存在有遗漏的情况特别折腾人，比如提测后执行了一个保存在代码里面的 sql，然后又出 bug 又写了增量脚本给测试执行，最后测试转预发布的时候运维又让给脚本中间可能就遗漏掉了或者预发布已经执行过部分脚本再全量执行会冲突。
--【肆】--：
没有特别好的管理系统的话，可以台账先行，统一记录好需求和SQL，再进行对应开发，再针对需求逐步测试及写发版文档，在文档中关联对应需求和SQL
--【伍】--：
有专门的集成工程师吗，负责编译和处理一些相关问题的
--【陆】--：
很难做到100%不遗漏吧，只能靠良好的习惯来尽可能避免，我是自己有个开发文档，对于每一个需求，记录了所有涉及的服务，开发分支，版本变化情况，SQL，配置变更等信息，即使是开发环境，也尽可能是先记录再执行。
当然我也有没记住的时候。
--【柒】--：
- 针对分支开发策略涉及到sql变更，参数配置变更的问题，我觉得在AI编程时代可以考虑所有资料/变更转为代码的一部分，即代码变化和资料配置变化一一对应，解决软件升级和资料升级，环境变更的版本对应问题
- 针对每个环境sql不知道执行到哪个位置的问题，可以考虑sql历史监控工具, 你说的flaway就有类似的功能， Exploring the Flyway Schema History Table | Redgate
--【捌】--：
我们目前是只要没进入提测都不记录sql，然后功能提测再汇总一个 sql 给到运维执行，但是提测后可能因为bug 要调整字段长度或者必填非必填等等，多给几次 sql 就不知道测试和预发布 sql 执行了几次。
--【玖】--：
- 团队开发可能不能单纯靠默契了，需要有流程看护，即代码合入时用ci手段强制检查是否有sql/资料关联，未关联不允许合入，资料/sql不允许出现在代码仓以外的地方
- 看了下这auto-ddl的功能应该就是history_of_sql表，可能有其他工具也有类似的能力，实在不行让天才程序员vibe一个？记录环境列表，环境执行的sql列表，sql migration列表，下次执行的自动检查进度去重…
--【拾】--：
当然不可能研发抗下所有的 软件有对应的软测部门 硬件同样有硬测部门
从研发到正式发布或者出货 需要过好几次全面测试 回归测试 还要有项目管理跟着
自测试不过是第一道门槛罢了
--【拾壹】--：
这个妙啊，但是作为打工人的话只想把自己的事给做好减少担责和绩效考核吧，也是为了方便自己减少遗漏，就是看有没有类似的开源项目可以固化下流程减少犯错
--【拾贰】--：
一说负责就要进行绩效结算了，从开发发测试，测试发预发布，预发布发生产这每条线上都可能存在遗漏，和我们发版的方式流程可能也有关系，举个例子：比如我开发一个 A 功能，开发过程中我记录所有的变动 sql，然后没问题我去提测把这些 SQL 给到运维执行，执行完测试在测试环境测试，测试过程中发现有问题要动表结构了我就又会继续记录 sql，然后去测试环境让运维执行，测试测得没问题了就会上预发布，上了预发布如果验证出问题了又要改 sql，继续进入测试，然后多改几次这次变动一共 3 次 sql，测试执行了 3 次，但是预发布可能只执行了 1 次或者 2 次，就不知道预发布下次应该执行哪些 sql 了。
--【拾叁】--：
现在这个流程是有的，每次发布会提前准备文档，里面会写数据库变动，界面配置，定时任务菜单等等的人工操作的步骤，我们目前没有固定的发版窗口，有可能有些功能开发很长时间才上线，发现很多对不齐哈哈哈哈，就是看有没有这方面的开源项目能够固化下来减少犯错和遗忘带来的损失
--【拾肆】--：
我司采用强制上线审核流程制度，从开发到运维，开发填写具体分支，sql以及配置回滚策略，测试负责审核上线回归，运维负责上线操作，漏了看下哪个环节的人员问题定责即可
--【拾伍】--：
1、所有人需要填升级方案，把所有步骤汇总
2、开一个升级方案评审会议（自己部分提前确认，会上快速对齐疑问点【执行顺序，是否存在其他依赖】）
3、需要一个灰度环境进行发布模拟
4、最后上线
--【拾陆】--：
只有一个运维工程师哇哈哈哈哈哈，运维要发布多个项目的各个环境，现在遇到的问题主要是 sql 遗漏的问题，界面上配置如果少了可以添加上影响倒不是很大
--【拾柒】--：
是的，自己都会用个小本本记还有代码根目录有个 sql 目录会记，但是总会有遗漏的时候，就是看有没有比如类似于这类开源产品可以进行固化下来，然后只要测试执行过的后续的环境都按照顺序直接执行了
--【拾捌】--：
那这还是得有个类似flyway管理方式，把每次SQL变更记录下来，运维执行到哪条也要有记录才行，从前往后执行，搞个在线Excel表做台账，搞个测试环境列，预发环境列，执行了SQL打个勾之类的，跳着执行肯定会乱的，可能没有什么好办法
--【拾玖】--：
开发需要对自己提交的并且经过评审的东西负责，灰度环境都有了，理论上不应该有问题遗留到正式环境
公司规模稍微比较小，但是还是有10 来个开发，我们分支策略是生产分支拉功能分支，然后本地自测完合开发分支，提测再从功能分支合并测试分支，测试没问题再从功能分支合并合并预发布分支，最终没问题再直接从预发布合并到生产分支。在这个开发过程中会涉及到数据库sql，界面上参数配置等等，每次都会写发布文档，但是对于sql可能在开发过程中多次调整，导致有些环境是执行了部分 sql，每次整理 sql 都不知道对应环境执行到哪个位置了，目前也没有采用 flyway 这种自动管控，请教各位佬们做开发如何做到发版不遗漏的呢。
网友解答：--【壹】--：
flyway 以前公司有用过，如果是单人开发并且数据库比较单一的话还行，我们项目有很大的定制化以及国产化数据的东西，用自动管控同时连开发库没拉别人的代码连同一个数据库会存在奇奇怪怪的问题，你说的这个 excel 表我们目前有个在线文档就是这样做的，但是给到这个 sql 链接是仓库地址链接会存在变动的情况，有点刻舟求剑的感觉
--【贰】--：
1.理想情况就是文档记录都是跟着代码仓库同步走，作为一个团队很难每个人都有那么默契
2.flyway 这个以前公司用过，有利有弊一直没有上，也看过 mybatisplus 自带的 autoddl 功能。https://baomidou.com/guides/auto-ddl/
--【叁】--：
道理是这个道理，也不是开发扛下所有，只是想把自己端口的事做好，每次发大版本的时候很多特性分支导致sql混乱得很还存在有遗漏的情况特别折腾人，比如提测后执行了一个保存在代码里面的 sql，然后又出 bug 又写了增量脚本给测试执行，最后测试转预发布的时候运维又让给脚本中间可能就遗漏掉了或者预发布已经执行过部分脚本再全量执行会冲突。
--【肆】--：
没有特别好的管理系统的话，可以台账先行，统一记录好需求和SQL，再进行对应开发，再针对需求逐步测试及写发版文档，在文档中关联对应需求和SQL
--【伍】--：
有专门的集成工程师吗，负责编译和处理一些相关问题的
--【陆】--：
很难做到100%不遗漏吧，只能靠良好的习惯来尽可能避免，我是自己有个开发文档，对于每一个需求，记录了所有涉及的服务，开发分支，版本变化情况，SQL，配置变更等信息，即使是开发环境，也尽可能是先记录再执行。
当然我也有没记住的时候。
--【柒】--：
- 针对分支开发策略涉及到sql变更，参数配置变更的问题，我觉得在AI编程时代可以考虑所有资料/变更转为代码的一部分，即代码变化和资料配置变化一一对应，解决软件升级和资料升级，环境变更的版本对应问题
- 针对每个环境sql不知道执行到哪个位置的问题，可以考虑sql历史监控工具, 你说的flaway就有类似的功能， Exploring the Flyway Schema History Table | Redgate
--【捌】--：
我们目前是只要没进入提测都不记录sql，然后功能提测再汇总一个 sql 给到运维执行，但是提测后可能因为bug 要调整字段长度或者必填非必填等等，多给几次 sql 就不知道测试和预发布 sql 执行了几次。
--【玖】--：
- 团队开发可能不能单纯靠默契了，需要有流程看护，即代码合入时用ci手段强制检查是否有sql/资料关联，未关联不允许合入，资料/sql不允许出现在代码仓以外的地方
- 看了下这auto-ddl的功能应该就是history_of_sql表，可能有其他工具也有类似的能力，实在不行让天才程序员vibe一个？记录环境列表，环境执行的sql列表，sql migration列表，下次执行的自动检查进度去重…
--【拾】--：
当然不可能研发抗下所有的 软件有对应的软测部门 硬件同样有硬测部门
从研发到正式发布或者出货 需要过好几次全面测试 回归测试 还要有项目管理跟着
自测试不过是第一道门槛罢了
--【拾壹】--：
这个妙啊，但是作为打工人的话只想把自己的事给做好减少担责和绩效考核吧，也是为了方便自己减少遗漏，就是看有没有类似的开源项目可以固化下流程减少犯错
--【拾贰】--：
一说负责就要进行绩效结算了，从开发发测试，测试发预发布，预发布发生产这每条线上都可能存在遗漏，和我们发版的方式流程可能也有关系，举个例子：比如我开发一个 A 功能，开发过程中我记录所有的变动 sql，然后没问题我去提测把这些 SQL 给到运维执行，执行完测试在测试环境测试，测试过程中发现有问题要动表结构了我就又会继续记录 sql，然后去测试环境让运维执行，测试测得没问题了就会上预发布，上了预发布如果验证出问题了又要改 sql，继续进入测试，然后多改几次这次变动一共 3 次 sql，测试执行了 3 次，但是预发布可能只执行了 1 次或者 2 次，就不知道预发布下次应该执行哪些 sql 了。
--【拾叁】--：
现在这个流程是有的，每次发布会提前准备文档，里面会写数据库变动，界面配置，定时任务菜单等等的人工操作的步骤，我们目前没有固定的发版窗口，有可能有些功能开发很长时间才上线，发现很多对不齐哈哈哈哈，就是看有没有这方面的开源项目能够固化下来减少犯错和遗忘带来的损失
--【拾肆】--：
我司采用强制上线审核流程制度，从开发到运维，开发填写具体分支，sql以及配置回滚策略，测试负责审核上线回归，运维负责上线操作，漏了看下哪个环节的人员问题定责即可
--【拾伍】--：
1、所有人需要填升级方案，把所有步骤汇总
2、开一个升级方案评审会议（自己部分提前确认，会上快速对齐疑问点【执行顺序，是否存在其他依赖】）
3、需要一个灰度环境进行发布模拟
4、最后上线
--【拾陆】--：
只有一个运维工程师哇哈哈哈哈哈，运维要发布多个项目的各个环境，现在遇到的问题主要是 sql 遗漏的问题，界面上配置如果少了可以添加上影响倒不是很大
--【拾柒】--：
是的，自己都会用个小本本记还有代码根目录有个 sql 目录会记，但是总会有遗漏的时候，就是看有没有比如类似于这类开源产品可以进行固化下来，然后只要测试执行过的后续的环境都按照顺序直接执行了
--【拾捌】--：
那这还是得有个类似flyway管理方式，把每次SQL变更记录下来，运维执行到哪条也要有记录才行，从前往后执行，搞个在线Excel表做台账，搞个测试环境列，预发环境列，执行了SQL打个勾之类的，跳着执行肯定会乱的，可能没有什么好办法
--【拾玖】--：
开发需要对自己提交的并且经过评审的东西负责，灰度环境都有了，理论上不应该有问题遗留到正式环境