这里按OpenText ALM也就是OpenText Application Quality Management来写。官方当前文档给出的口径很明确，ALM和Jira的同步是通过Connect来做，Connect可以同步Stories、Requirements、Tasks这一类资产；ALM这一侧的AQM连接器支持Requirements、Defects、Tests以及自定义字段。也就是说，真正落地时不是在ALM里单独开一个Jira开关，而是先准备Connect，再分别定义ALM和Jira两端的数据源与连接。

　　一、ALM怎么对接Jira

　　这一步最重要的，不是先点映射，而是先把接入前提和两边的数据源建对。官方用例明确写到，Jira侧必须有一个包含项目全部内容的board，因为Connect是从board读取Jira内容；Jira账号还要求使用英文界面；如果是Jira Cloud，则连接时填用户和token。ALM侧则需要对要同步的域和项目有完整读写权限。

　　1、先准备Connect和两端账号

　　先装好Connect，并补装Jira connector，因为官方说明Jira connector不在默认安装包里。账号方面，ALM侧准备有读写权限的用户，Jira侧准备有项目读写权限的用户。Jira Cloud用用户和token，本地Jira用服务器地址加账号密码。

　　2、先建ALM数据源

　　在Connect的【Data Sources】里点【+Data Source】，产品选择OpenText Application Quality Management，然后依次填写服务器、端口、账号、域和项目。官方用例里还要求在这一步选好default cycle parent和requirement parent，因为Jira的sprint可以不挂release，但ALM的cycle必须挂在release下面。

　　3、再建Jira数据源

　　继续在【Data Sources】里新建Jira数据源，填Jira URL、账号和认证信息，然后选项目，再选board。官方建议单独建一个给Connect使用的board，尽量不要直接复用个人看板，不然过滤条件一改，就可能影响Connect的可见范围。

　　4、进入连接向导创建Connection

　　在【Connections】里点【+Connection】，命名后把OpenText Application Quality Management和Jira选进来。官方用例里默认把ALM放在master，Jira放在target，然后进入【Types and Fields】继续配置。这里默认的【Default Sync Direction】就是bi-directional，但官方也明确提醒，真正的创建方向和更新方向，要在类型级和字段级分别改，不要只看这个总开关。

　　5、先跑一轮单次同步再转持续同步

　　连接配完以后，先在连接菜单里执行【Run One Iteration】做一次验证，确认类型、字段和值映射都没有问题，再用【Start Connection】转成持续同步。这样一开始就能看出是数据源问题、字段问题，还是值映射问题。

　　二、ALM需求与缺陷双向同步怎么配

　　真正难的地方在这一段。官方文档虽然给了默认双向同步方向，但类型和字段并不建议一刀切都做成双向。官方示例里，Jira的Story和Epic到ALM Requirement，创建方向设为Jira到ALM，也就是先由Jira推Requirement过来；但字段更新可以再单独改成双向。至于Bug和Defect，官方示例则明确说可以保留bi-directional。

　　1、需求同步先分清创建方向和更新方向

　　如果你的主需求源在Jira，就在【+Type Mapping】里把Story对Requirement、Epic对Requirement建出来，然后把类型的Direction设成【To Master】这一类单向创建方式。这样Jira新建Story或Epic时可以推到ALM，但不是两边同时乱建。等基础字段跑顺以后，再把名称、描述、优先级这类字段调成双向更新。

　　2、缺陷同步更适合做真正双向

　　官方用例直接给了Bug和Defect双向同步的思路，也就是缺陷可以在任一侧产生，再同步到另一侧。因此这块更适合保留bi-directional，但前提是状态、优先级、严重级别这类枚举值先做value mapping，不然两边字段名相同也会因为值域不同而报错。

　　3、需求字段里，父子关系字段不要直接全双向

　　官方示例特别点出了一个例外，Epic Link到ALM的parent-id建议单向映射，因为它本质上是关系字段，不是普通文本字段。官方还提醒，像Sprint这种link field，要等基础实体先同步完成以后，再回来补链路字段；如果不确定某个字段是不是link field，可以去数据源的【Relationships】里看。

　　4、ALM侧先开History，不然双向更新看不到变更

　　AQM连接器的readme写得非常直接，ALM如果要让Connect识别字段变更，必须先在【Tools】里的【Customize】进入【Project Entities】，把要同步的字段打开【History】。这一步至少要对Requirement和Defect里准备参与同步的系统字段做，不然你以为是双向，实际上Connect可能根本看不到ALM侧更新。

　　5、列表值、必填字段、评论规则都要先单独收口

　　官方用例里明确写到，像Priority这样的list field通常都要做value mapping，而且界面里如果某一侧字段是必填，会用红色标出来，必须补齐映射。AQM连接器还说明comments是通过Related Comments同步的，但目前只支持同步新评论，不支持评论更新和删除；另外，ALM侧删除记录无法被连接器检测到，所以另一侧不会跟着删。

　　三、ALM对接Jira前哪些同步口径要先定

　　前两段解决的是怎么接和怎么配，真正决定后面稳不稳的，其实是几个口径要不要先收好。官方文档已经把几个容易翻车的点说得很清楚，提前定住会省很多返工。

　　1、先定需求放进ALM哪个树节点

　　AQM数据源和Requirement同步都依赖parent。官方readme明确要求Requirement Parent Folder ID，官方Jira用例也让你在ALM里先选requirement parent。需求树节点没定好，后面Requirement会散到根下或默认目录里，越跑越乱。

　　2、先定需求重名怎么处理

　　官方readme提到，Jira Story同步到ALM Requirement时，ALM会在配置的requirement tree分支里按名称尝试匹配；同一分支里如果已经有同名Requirement，就不会新建，而是更新cross reference。因为ALM不允许同一分支下有多个同名Requirement，所以需求命名规则最好先统一。

　　3、先定哪些关系字段只做单向

　　官方明确建议，ALM的link和trace属性更稳妥的做法是做one-way，因为删除关系时ALM不一定更新修改时间；如果硬设双向，有可能被另一侧旧值反写回来。这个规则对需求关联、父子链路、追踪关系尤其要先定。

　　4、先定筛选范围，不要一上来全量跑

　　官方用例里既建议Jira侧用专用board，也允许按Types收窄同步范围；AQM readme还建议优先使用named filter，而不是随手写free-form filter，因为ALM的REST查询需要字段名，不是界面标签。范围先收小，性能和排错都会稳定很多。

　　总结

　　ALM怎么对接Jira，真正的落地路径是用Connect分别建ALM和Jira数据源，再通过Connection去做类型、字段和值映射，而不是只在ALM本体里找一个同步按钮。ALM需求与缺陷双向同步怎么配，重点也不是把所有开关都拨成双向，而是把需求的创建方向、字段更新方向、父子关系字段、缺陷双向规则、History、value mapping、评论和删除策略分开处理。这样接起来以后，需求不会乱进树，缺陷也更不容易出现互相覆盖和反写。