需求是产品的源头，其重要性不言而喻。然而，在传统产品交付实践中，需求跟踪与工程交付过程往往是割裂的，同时存在大量碎片化的工作。这种传统方式带来一系列痛点：
- 沟通障碍：需求通过非正式渠道传递，造成信息不准确和难以追踪，影响团队合作。
- 交付瓶颈：缺乏自动化导致研发周期长，任务重复，增加错误和延误风险。
- 项目监控不足：缺少对项目全貌的清晰了解，使得决策和优化变得困难。
- 协作低效：团队需在多个工具间切换，增加了工作负担和协作难度。
为了解决这些痛点，Zadig 与主流项目管理工具 Jira 无缝连接，优雅地解决了以上问题，并实现了产研团队之间的顺畅协作。接下来我们用一个 「Geek 」项目，来介绍如何配置 Jira 和 Zadig ，并采用一个真实的产品研发场景作为例子，一起体验整个自动化协作过程。
# 项目背景介绍
产品经理根据「Geek 」项目上线目标，制定版本发布计划，对需求进行拆解后在 Jira 中依次建立 Epic-> 故事 -> 问题跟踪，并为任务关联版本信息，包括以下 3 种类型的问题：
- 任务：用于记录需求拆解完毕后，进入到研发环节的一系列待开发任务项
- 缺陷：用于记录对历史版本的缺陷修复，或测试验证阶段新发现的缺陷
- 发布：发布计划，其中关联该版本待发布的任务信息
任务/缺陷的状态流转示意图如下：
发布的状态流转示意图如下：
# 管理员如何配置
管理员（比如：运维工程师）在 Zadig 中集成 Jira，并实现研发、测试、运维日常协同合作所需的工程基础配置：包括不同角色所需要的环境和工作流。
# 集成 Jira
在 Zadig 中集成 Jira，参考文档：Jira 集成 (opens new window)。
# 配置环境
平台（运维）工程师在 Zadig 上准备好目标协作环境，具体配置参考：
| 面向角色 | 名称样例 | 环境描述 | 对应代码 | 场景描述 |
|---|---|---|---|---|
| 开发工程师 | dev | 开发环境 | develop 分支 + PR（feature 分支向 develop 分支提交） | 需求实现后，在 dev 环境部署生效并自测，自测没问题后提测 |
| 测试工程师 | sit | 日常测试验证环境 | develop 分支 + PR（feature 分支向 develop 分支提交） | 需求研发完毕后，可以基于代码变更在 sit 环境中对需求进行测试验证，验证通过后合并 PR |
| uat | 预发布、集成验证环境 | main 分支 + PR（develop 分支向 main 分支提交） | 当版本中规划任务实现完毕且验收通过后，基于主干分支 + PR 发布 uat 环境进行集成验证，验收通过后及时合并代码。 用于生产环境发布前验收测试。 | |
| 发布工程师 | prod | 生产环境 | main 分支 | 生产发布，对生产环境的变更需要经过严格的审批 |
# 配置工作流
平台（运维）工程师在 Zadig 中准备好目标协作工作流，具体配置参考：
| 面向角色 | 功能描述 | 工作流名称样例 | 具体配置 |
|---|---|---|---|
| 研发工程师 | 日常更新开发环境 | workflow-dev | 变更任务状态（待办 -> 进行中） -> 构建 -> 部署 -> 自动化测试 -> IM 通知 |
| 测试工程师 | 日常更新测试环境 | workflow-sit | 构建 -> 部署 sit 环境 -> 自动化测试 -> 变更任务状态（测试中 -> 待发布） |
| 更新集成测试环境 | workflow-uat | 构建 -> 部署 uat 环境 -> 自动化测试 -> 变更发布状态（待办 -> 进行中） | |
| 发布工程师 | 更新生产环境 | workflow-prod | 审批 -> 部署生产环境 -> 变更发布任务状态（待发布 -> 完成） |
# 项目状态变更配置
将 JIRA 问题状态变更任务 编排到工作流中，即可完成项目状态自动变更与工作流的关联配置。以 dev 工作流为例，其他工作流的配置也是类似的，这里不再赘述。
操作步骤：编辑 dev 工作流 -> 添加 JIRA 问题状态变更任务 -> 填写任务配置后保存。
具体配置信息可参考：
- 任务名称：
start-develop，根据实际语义配置。 - Jira 项目：
Geek 项目，选择 Jira 中与该研发团队对应的项目。 - JQL 搜索：
issuetype in (任务, 缺陷) And status = "待办"，Jira 支持的标准 JQL 语句。 - 变更问题：无需配置，执行工作流时指定。
- 目标状态：
进行中，选择需要自动变更的目标状态。
# 团队敏捷协同场景
以下场景涵盖研发过程中涉及到的独立开发、多方联调、开发和测试协同、回归测试验证、正式发布上线等主要协作过程，通过 Zadig 工作流自动化触发 Jira 中任务/缺陷/发布类型问题的状态流转，实现高效的自动化协作。
# 开发独立自测场景
任务/缺陷状态自动触发：待办 -> 进行中
代码实现完毕后提交代码变更 PR 到远端仓库，执行 dev 工作流，选择对应JIRA 问题、服务、代码变更 PR 即可。
# 多个开发联调协作场景
任务/缺陷状态自动触发：待办 -> 进行中
代码实现完毕后提交代码变更 PR 到远端仓库，执行 dev 工作流时选择需要联调的多个变更问题、服务和 PR 即可。
# 功能测试验证场景
任务/缺陷状态自动触发：测试中 -> 待发布
研发提测后，基于代码变更运行 sit 工作流更新 sit 环境，执行步骤包括构建 -> 部署 -> 自动化测试 -> 变更任务状态，在 sit 环境中开展日常测试验收工作：
- 验证通过后，对应的 JIRA 任务状态调整为
待发布。 - 验收不通过时，将 JIRA 任务状态调整为
进行中并和研发同步验收失败原因，减少信息 Gap。 - 对新功能手工验证后分析测试报告，基于覆盖情况持续补充自动化用例集，确保自动化测试套件和业务功能一起迭代，持续为团队提供价值。
# 集成测试验证场景
发布 状态自动触发： 待办 -> 进行中
在版本正式发布前基于 main 分支 + PR 执行 uat 工作流部署 uat 环境，执行步骤包括：构建 -> 部署 -> 系统集成测试 -> 变更任务状态。若集成测试通过，则一键变更发布状态为进行中 。
集成验证通过后，版本发布负责人及时合并代码变更至 main 分支。
# 正式发布上线场景
Zadig 工作流自动触发发布状态变更： 进行中 -> 完成
当整个版本验收通过后，执行 prod 工作流执行生产发布，审批通过后方可发布，更新完成后一键关闭发布任务。建议几种配置策略：
- 测试验收通过的版本才允许发布，从流程上建设发布门禁。
- 灵活编排蓝绿、金丝雀、分批次灰度、Istio 等发布策略，以确保发布的可靠性，可参考：发布策略 (opens new window)。
- 工作流适当增加人工审批，以确保业务流程上的发布合规性。
# 管理员进阶场景
除了一线工程师的协作日常场景外，团队层面也需要关注一些必要的管理操作，比如统一更新环境，收集项目整体状态等。
# 项目管理的质效可视化
Jira 项目管理数据与 Zadig 工程数据打通，实现统一的指标管理可视化。
基于 Zadig 和 Jira 双向互联协作产生了全生命周期的效能数据，可以通过 Zadig 自定义效能指标，添加进度项：平均需求交付周期、需求研发交付周期。该例中数据来源于 Jira，需少量的指标项开发。企业可通过定制 XOps 敏捷效能看板，通过项目评分比对识别短板，根据企业现状制定效能目标，用数据驱动改进。
# 自动更新所有开发测试环境
Jira 发布任务状态变更，自动触发工作流更新环境。
当一个生产版本发布完成后，可以基于主干 main 分支一键更新所有开发、测试环境到最新稳定版本，让研发和测试专注在需求实现和需求质量保证上，降低日常对于环境管理的心智负担。
工作流包含构建 -> 部署开发环境 -> 部署测试环境，配置 Jira 触发器可参考文档：Jira 触发器 (opens new window)。
Zadig 与 Jira 的结合为产品、研发、运维团队提供了一个工程化的协作平台。从需求开发到实现、测试验证、发布生产，直至需求关闭，整个流程都能得到有效管理。项目管理人员可以实时监控项目进展，确保项目能够以高质量和敏捷的方式顺利交付。这种协作方式能够激发团队的潜力，也为企业的可持续发展和成功打下了坚实的基础。
