![]()
01、痛点
需求是产品的源头，其重要性不言而喻。然而，在传统的产品交付实践中，需求拆解为具体的任务后，交由研发进行交付和发布，而需求跟踪与工程交付往往是割裂的，存在大量碎片化的工作。这带来了一系列痛点：
-
分散的工具和流程：需求对齐依赖口头传递，导致信息失真，难以追溯。这使得沟通和协调变得困难，阻碍团队实现高效的协作和可视化。
-
缺乏持续交付能力：流程和研发交付脱节，手动操作、重复的任务和长周期的交付过程增加了开发时间，提高了错误风险，减慢了交付速度。
-
缺乏可视化和洞察力：缺乏对项目状态、工作进展和问题的全面洞察能力，导致决策困难，错失优化机会，并且无法准确把握项目整体健康状况。
-
集成和协作困难：团队成员在不同的工具之间来回切换，增加了工作复杂性和协作难度。
为了解决这些痛点，ZadigX 与业界公认的最专业项目管理工具 Jira 实现了无缝连接，优雅地解决了这些问题，并实现了产研团队之间的顺畅协作。同时，基于数学模型，它还能客观度量需求研发交付的质量、效率、成本构成和进度情况。
![]()
接下来我们用一个 「Geek 」项目，来介绍如何配置 Jira 和 ZadigX ，并采用一个真实的产品研发场景作为例子，一起体验整个自动化协作过程。
02、项目背景介绍
产品经理根据「Geek 」项目上线目标，制定版本发布计划，对需求进行拆解后在 Jira 中依次建立 Epic-> Story -> Issue 跟踪，并为 Issue 关联版本信息，包括以下 3 种类型的 Issue：
![]()
任务/缺陷的状态流转示意图如下：
![]()
发布的状态流转示意图如下：
![]()
03、管理员如何配置
管理员（比如：运维工程师）在 ZadigX 中集成 Jira，并实现研发、测试、运维日常协同合作所需的工程基础配置：包括不同角色所需要的环境和工作流。
集成 Jira 在 ZadigX 中集成 Jira，参考文档：Jira 集成[1]。
![]()
配置环境平台（运维）工程师在 ZadigX 中准备好目标协作环境，具体配置参考。
![]()
配置工作流平台（运维）工程师在 ZadigX 中准备好目标协作工作流，具体配置参考。
![]()
项目状态变更配置将 <JIRA 问题状态变更任务>编排到工作流中，即可完成项目状态自动变更与工作流的关联配置。以<dev>工作流为例，其他工作流的配置也是类似的，这里不再赘述。
操作步骤：编辑<dev>工作流 -> 增加提测阶段 -> 添加 JIRA 问题状态变更任务 -> 填写任务配置后保存。
具体配置信息可参考：
-
任务名称：<request-for-test>，根据实际语义配置。
-
Jira 项目：<Geek 项目>，选择 Jira 中与该研发团队对应的项目。
-
JQL 搜索：<issuetype in (任务, 缺陷) And status = "In Progress" >，Jira 支持的标准 JQL 语句。
-
变更问题：无需配置，执行工作流时指定。
-
目标状态：<Testing>，选择需要自动变更的目标状态。
![]()
4、团队敏捷协同场景
以下场景涵盖研发过程中涉及到的独立开发、多方联调、开发和测试协同、回归测试验证、正式发布上线等主要协作过程，通过 ZadigX 工作流自动化触发 Jira 中任务/缺陷/发布类型 Issue 的状态流转，实现高效的自动化协作。
开发独立自测场景任务/缺陷状态自动触发：TODO -> In Progress 代码实现完毕后提交代码变更 PR 到远端仓库，执行 dev 工作流，选择对应 Issue、服务、PR 即可。
![]()
多个开发联调协作场景任务/缺陷状态自动触发：TODO -> In Progress 代码实现完毕后提交代码变更 PR 到远端仓库，执行 dev 工作流时选择需要联调的多个 Issue、服务和 PR 即可。
![]()
开发与测试协作场景任务/缺陷状态自动触发：In Progress -> Testing 执行 dev 工作流更新 dev 环境并进行自测，当认为自测没问题后，自己审核通过即可自动提测，变更 Issue 状态为 Testing，并且将工作流执行状态同步到 IM 中，以便测试工程师及时感知需求进展，尽早验收把关质量。
提示：如果自动化建设完备，覆盖率高，则可以去掉开发人工审核是否可提测这一步，自动化测试通过后即可自动提测。
![]()
功能测试验证场景 任务/缺陷状态自动触发：Testing -> To Be Released 研发提测后，基于代码变更运行 sit 工作流更新 sit 环境，执行步骤包括构建 -> 部署 -> 自动化测试 -> Issue 变更，在 sit 环境中开展日常测试验收工作：
-
验收不通过时，手动将 Issue 状态调整为 In Progress 并和研发同步验收失败原因。此举可促进团队充分沟通，减少信息 Gap。
-
对新功能手工验证后分析测试报告，基于覆盖情况持续补充自动化用例集，确保自动化测试套件和业务功能一起迭代，持续为团队提供价值。
-
验证通过后一键将测试通过的 Issue 状态调整为 To Be Released。
![]()
集成测试验证场景发布 Issue 状态自动触发：To Do ->To Be Released 在版本正式发布前基于 main 分支 + PR 执行 uat 工作流部署 uat 环境，执行步骤包括：构建 -> 部署 -> 系统集成测试 -> Issue 状态变更。若集成测试通过，则一键变更发布 Issue 状态为 To Be Released。
集成验证通过后，版本发布负责人及时合并代码变更至 main 分支。
![]()
正式发布上线场景ZadigX 工作流自动触发发布 Issue 状态变更：To Be Released -> Done 当整个版本验收通过后，执行 prod 工作流执行生产发布，审批通过后方可发布，发布完成后一键关闭发布 Issue。建议几种配置策略：
-
测试验收通过的版本才允许发布，从流程上建设发布门禁。
-
灵活编排蓝绿、金丝雀、分批次灰度、Istio 等发布策略，以确保发布的可靠性，可参考：发布工作流[2]。
-
发布工作流适当增加人工审批，以确保业务流程上的发布合规性。
![]()
05、管理员进阶场景
除了一线工程师的协作日常场景外，团队层面也需要关注一些必要的管理操作，比如统一更新环境，收集项目整体状态等。
项目管理的质效可视化 Jira 项目管理数据与 ZadigX 工程数据打通，实现统一的指标管理可视化。
基于 ZadigX 和 Jira 双向互联协作产生了全生命周期的效能数据，可以通过 ZadigX 自定义效能指标，添加进度项：平均需求交付周期、需求研发交付周期。该例中数据来源于 Jira，需少量的指标项开发。企业可通过定制 XOps 敏捷效能看板，通过项目评分比对识别短板，根据企业现状制定效能目标，用数据驱动改进。
![]()
自动更新所有开发测试环境 Jira 发布 Issue 状态变更，自动触发工作流更新环境。当一个生产版本发布完成后，可以基于主干 main 分支一键更新所有开发、测试环境到最新稳定版本，让研发和测试专注在需求实现和需求质量保证上，降低日常对于环境管理的心智负担。
工作流包含构建 -> 部署开发环境 -> 部署测试环境，配置 Jira 触发器可参考文档：Jira 触发器[3]。
![]()
ZadigX + Jira 可以贯穿需求从开发实现 -> 测试验证 -> 发布生产 -> 需求关闭的整个流程，为产品、研发、运维提供工程化协作底座，项目管理人员也可以实时观测项目进展，确保项目高质量敏捷交付，创造 1+1 > 2 的团队合作效果。
参考链接
[1]Jira 集成：https://docs.koderover.com/zadig/ZadigX%20v1.5.0/settings/jira/
[2]发布工作流：https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/release-workflow/
[3]Jira 触发器：https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/workflow-trigger/#jira-
推荐阅读
Zadig 和 ZadigX 究竟有什么区别
ZadigX 发布：价值驱动一切 链接最酷玩家
ZadigX 上线飞书官方：先进组织，一站式高效协同解决方
极氪、路特斯、光环有云：我如何从开源 Zadig 走向 ZadigX 商业合作
阅读原文 https://mp.weixin.qq.com/s/y4E2AXGQqs8EuT-tMYeCPw
