私有化部署研发管理平台与测试平台打通的3种方式

私有化部署研发管理平台与测试平台，常常各自运行。需求评审在一边，测试用例、执行记录和 Bug 在另一边。团队看到的是两套项目、两套账号、两套状态，最后靠表格和群消息对齐。所谓“打通”，不是把两个系统用一根接口连起来，而是让数据、身份和事件在受控的网络里各走其道。下面把常见的三种方式拆开讲，重点说清楚各自适合什么条件、要付什么成本、在私有化环境里容易卡在哪里。

先分清数据、身份、事件三层

不少“打通”项目失败，不是接口写不出来，而是目标没有拆开。可以用三个问题判断：

• 数据层：需求、用例、Bug、测试结果，以哪边为准？
• 身份层：账号、组织、角色，由谁统一维护？
• 事件层：测试完成、构建失败、状态变更，谁来触发下一步？

这三层可以分开实施。只做身份，用户少登录一次，但数据仍要手工搬；只做数据，账号和权限仍要维护两套；只做事件，历史数据不会自动补齐。先定对象、方向、触发条件和责任人，再谈接口。

方式一：API 接口同步，打通需求、用例与 Bug 数据

先看数据层，直接的做法是 API 同步。

适合谁，怎么做

当测试平台有独立的用例和 Bug 模型，且两边都需要保留自己的操作习惯时，API 同步更合适。做法不建议一上来就全对象双向同步，先选一条最小链路：研发管理平台的需求同步到测试平台，测试平台执行后产生的 Bug 和结果回写到研发管理平台。

落地时先做四件事：

1. 建对象映射：需求对应测试需求或用例集，测试计划对应迭代或版本，Bug 对象一一对应。
2. 定字段归属：标题、状态、优先级、处理人分别由哪边维护，避免两边互相覆盖。
3. 存外部标识：每条数据保留来源系统、来源 ID 和最后同步时间，不能靠标题匹配。
4. 设计失败处理：重复提交要幂等，失败要可重试、可告警、可补偿。

接口认证按版本选择。禅道 API 2.0 使用 token 认证，请求时把 token 放在 header；较早的第三方集成方式使用 code、time、token 签名，时间戳只能使用一次。新项目优先用 API 2.0，已有集成可以继续沿用旧接口，官方发布说明称 API 1.0 会继续维护。具体字段和调用方式以禅道 API 开发手册为准。

成本与限制

API 同步的开发量较大，维护周期也较长。字段语义、状态流和权限模型都会随版本变化，升级前要回归。同步延迟取决于轮询频率或事件机制，不能默认实时。私有化网络里还要处理反向代理、证书信任、IP 白名单和跨网段访问。

数据能同步之后，账号和权限仍然是两套，接着看身份层。

方式二：统一身份认证与单点登录，打通账号、组织与权限

适合谁，怎么做

多团队、多项目并行，人员流动频繁，或者有审计要求时，账号不统一会带来两类问题：员工记多套密码，管理员维护多套权限。先把身份源定下来，再选协议。常见做法是以企业目录服务为主，禅道通过 LDAP 接入，支持从目录导入用户；测试平台侧确认是否支持 LDAP、OIDC 或 SAML，如果不支持，就用统一门户做跳转。

禅道官方文档显示，LDAP 功能依赖 PHP 的 LDAP 扩展，配置入口在“后台-系统设置-LDAP”，可以选择活动目录，也可以从 LDAP 导入用户并绑定本地账号。另一个容易混淆的能力是免密登录：禅道从 11.5.1 版本开始支持第三方应用免密登录，通过 account、code、time、token 生成带签名的登录地址，时间戳一次有效。它适合从门户跳到禅道，但不等于完整的身份联邦，账号生命周期和权限映射仍要单独治理。

如果测试工作主要由禅道内置的测试管理承接，账号和权限本来就在同一套体系里，集成范围会小很多。

成本与限制

单点登录解决的是“登录一次”，不自动解决“项目权限对不对”。 组织架构、离职转岗、外包账号、共享账号、跨部门项目，都要有明确规则。私有化环境还要统一时钟，否则签名时间戳容易失效；证书、回调和白名单也要提前打通。建议保留一个本地管理员账号作为应急入口。

身份统一解决的是入口，测试执行过程中的状态变化，还需要事件联动。

方式三：Webhook 与流水线联动，打通测试执行与结果回写

适合谁，怎么做

当团队已经有持续集成和自动化测试，测试平台跑完用例后，结果需要自动回到研发管理平台，或者触发 Bug、变更状态、发送通知，这时用事件联动更合适。

禅道从 9.6 版本开始内置 Webhook 功能，可以在后台配置 hook 地址，把 JSON 格式的数据发送到第三方服务。配置时要关注四件事：触发动作不能全为空，否则不会发送；发送方式选同步还是异步；关联产品和项目决定消息范围；参数类型决定 payload 里能带哪些字段。测试平台侧则通过 API Key 或流水线插件触发测试任务，完成后回调结果。

事件设计要防三个问题：重复事件、事件环路、失败无感知。每条事件带唯一 ID，消费端做幂等；状态回写不要再触发同一条 Webhook；失败进入重试队列，超过次数告警。涉及流水线时，可以把 DevOps 工具链作为事件总线，但不要让它承担大批量历史数据迁移。

成本与限制

Webhook 适合传递“发生了什么”，不适合承载大批量历史数据迁移。 它的实时性好，但可靠性依赖网络和消费端。私有化环境里，测试平台不一定能直接访问研发管理平台，可能需要 DMZ 中转或轮询兜底。事件顺序、重复投递、日志追踪都要设计，排障成本比 API 同步更高。

三种方式各自成立，接下来把它们放在同一组维度下比较。

三种方式怎么选

对私有化部署研发管理平台与测试平台来说，选型不是选功能最多的方案，而是选与当前网络、组织和版本条件匹配的组合。把三种方式放在同一组维度下比较，差别会更清楚。

三种方式没有统一赢家。 身份打通是底座，数据同步决定信息是否一致，事件联动决定反馈是否及时。更常见的做法是选两种组合，而不是只选一种。

• 已有独立测试平台，先做统一身份，再做需求到 Bug 的单向同步。
• 已有稳定流水线和自动化测试，在单向同步之上加 Webhook，把执行结果回写。
• 测试工作主要在禅道内完成，优先用内置测试管理，减少一套集成。
• 跨网段、强隔离环境，优先 API 或文件交换，Webhook 只放在可控区域。

私有化环境的实施顺序与验收

建议按“身份 → 单向数据 → 事件 → 治理”的顺序推进。先统一账号，再做一条需求到 Bug 的最小链路，最后加自动触发。每步都要有可观察结果，不要用“无缝打通”作为验收描述。

检查清单可以按下面几项展开：

• 字段映射：抽查 20 条需求、用例和 Bug，字段值和关联关系正确。
• 幂等与补偿：同一事件重复提交，不产生重复数据；失败可查、可重试。
• 权限与审计：同步账号不能越权；关键操作有操作者、时间和来源记录。
• 网络与证书：反向代理、证书信任、时钟同步、IP 白名单全部验证。
• 版本升级：升级前跑一遍回归，确认接口字段和状态流没有变化。
• 数据边界：测试数据不出内网；日志不记录敏感字段；备份和回滚路径可用。

接口调通只说明连接成立，验收要说明业务结果成立。 最后回到选型。私有化部署研发管理平台与测试平台打通，目标不是让系统数量变多，而是减少重复录入、减少状态失真、让质量数据可追溯。先选一条最小闭环，跑稳后再扩展，比一次性上全套集成更可控。

参考资料

• 禅道 APIv2.0 使用教程：https://www.zentao.net/book/api/2309.html
• 禅道 LDAP：https://www.zentao.net/book/zentaopms/994.html
• 禅道集成 Webhook：https://www.zentao.net/book/zentaopms/webhook-288.html
• 在第三方应用中集成禅道：https://www.zentao.net/book/zentaopms/integration-287.html
• 第三方应用配置免密登录禅道：https://www.zentao.net/book/zentaopmshelp/344.html