影刀RPA 流程发布与版本管理本地开发到生产上线的规范流程“这个流程上周还能跑的这周怎么不行了” — 因为你直接在正式环境上改代码。RPA流程虽然不像软件工程那么重型但基本的版本管理规范还是需要的。这篇文章给出一套轻量级的流程发布规范。为什么需要版本管理改坏了能回退。在正式流程上直接改改坏了就是你唯一的版本。没有备份回不了头。多人协作不冲突。A和B同时改同一个流程互相覆盖对方的修改。知道什么时候改了什么。出了问题能追溯到是哪个版本引入的。正式环境稳定运行。测试通过后再上线而不是改完了直接跑。目录结构规范project/ main.flow ← 当前正式版本只读 config/ settings.json ← 配置文件 settings.test.json settings.prod.json subflows/ ← 子流程目录 01_login.flow 02_collect.flow 03_process.flow modules/ ← Python模块 logger.py utils.py versions/ ← 历史版本存档 v1.0_20260601/ main.flow subflows/ v1.1_20260615/ main.flow subflows/ v2.0_20260701/ ← 当前开发版 main.flow subflows/ temp/ ← 临时文件目录 logs/ ← 运行日志店群矩阵自动化突破运营极限版本迭代流程1. 开发阶段 ↓ 2. 自测通过 ↓ 3. 发布到versions/目录打版本号 ↓ 4. 更新正式流程文件 ↓ 5. 首次上线后观察运行结果 ↓ 6. 如果有问题 → 从versions/恢复上一个版本打版本每次正式发布前把当前所有文件复制到 versions/ 目录下 versions/ v1.0_20260701/ main.flow config/ subflows/ modules/ 命名规则v{主版本}.{次版本}_{日期} v1.0_20260701 → 主版本1次版本02026年7月1日发布 v1.1_20260715 → 小改动次版本1 v2.0_20260801 → 大改动主版本1操作方式在文件夹里手动复制粘贴或者写个简单的Python脚本自动化。配置环境隔离测试环境和正式环境用不同的配置文件通过环境变量切换# config/settings.json — 公共配置# config/settings.test.json — 测试环境专用覆盖公共配置里不同的部分# config/settings.prod.json — 正式环境专用importjsonimportosdefload_config():envos.environ.get(RPA_ENV,TEST)# 加载公共配置withopen(config/settings.json,r,encodingutf-8)asf:configjson.load(f)# 加载环境专用配置env_filefconfig/settings.{env.lower()}.jsonifos.path.exists(env_file):withopen(env_file,r,encodingutf-8)asf:env_configjson.load(f)config.update(env_config)returnconfig发布检查清单每次发布前逐项确认检查项说明☐ 自测通过在测试环境跑完整流程数据正确☐ 配置文件已切换确认连接的是正式数据库/正式API☐ 测试残留已清理测试数据、测试账号、调试日志已移除☐ 旧版本已存档当前正式版已复制到versions/☐ 通知相关人员告知本次更新的内容和影响☐ 回滚方案就绪如果新版本有问题如何快速切回旧版多人协作规范如果多人维护同一个项目的流程文件1. 各自开发合并时人工协调。A改采集流程B改处理流程。各自的改动在自己的文件里合并时只互相通知。不需要Git因为影刀的.flow文件是二进制或特殊格式Git没法merge。2. 文件命名约定。temu店群自动化报活动案例如果多人可能同时改同一个文件用日期做后缀区分02_collect_20260701_A的修改.flow 02_collect_20260702_B的修改.flow 合并时人工对比两者的差异融合到一个新文件 02_collect_20260703_合并版.flow3. 谁在改什么写到项目README里。当前开发状态2026-07-01 - main.flow — 林焱在改增加重试逻辑 - 02_collect.flow — 稳定不要动 - 03_process.flow — 小王在改增加数据校验看起来很土但对于小团队来说比Git简单直接。回滚操作如果新版本上线后出问题1. 停止定时任务避免继续用新版本跑 2. 从 versions/ 目录找回上一个版本 3. 覆盖正式流程文件 4. 启动定时任务 5. 验证旧版本是否正常运行 6. 通知相关人员已回滚到v1.0回滚时注意如果新版本改了数据库表结构或数据回滚后的旧版本可能不兼容新结构。所以大版本升级时数据库改动和流程改动要分开发布。总结RPA版控不需要搞Git那么重。核心就三件事——改之前备份versions/目录、测试环境和正式环境用不同配置切换、发布前对照检查清单逐项确认。这套流程在大多数人少的RPA团队里完全够用。作者林焱
