如何在单个Bitbucket Pipeline中跟踪多仓库的部署与提交？

核心结论 #

Bitbucket目前没有原生支持让自定义流水线关联多个仓库的功能，确实需要向Atlassian提交功能请求。

可行替代方案 #

1. Git子模块方案 #

将后端、前端仓库作为配置仓库的Git子模块：

• Bitbucket和Jira对这类场景有部分支持：流水线运行时，Bitbucket会识别子模块的提交哈希，但不会自动将这些提交关联到部署记录；Jira能识别子模块提交消息中的Jira问题键（如PROJ-123），只要提交消息格式正确就能关联对应工作记录。
• 操作要点：每次部署前，需要在配置仓库中更新子模块的引用（提交子模块的最新哈希到配置仓库），这样配置仓库的提交记录就能间接关联前后端的最新变更，部署记录也能体现这些内容。
• 缺点：子模块维护成本较高，团队成员需要熟悉子模块操作，避免出现引用不一致的问题。

2. 虚拟提交方案 #

通过自动化流程推送包含前后端变更摘要的虚拟提交到配置仓库：

• 实现步骤：
  • 搭建一条自动化流水线，用来收集后端、前端仓库的最新提交信息（比如提交哈希、提交消息、关联的Jira问题键）。
  • 在配置仓库的指定分支（如deploy-tracking）或主分支上推送一条虚拟提交，提交消息需包含关键信息，示例：Deploy: backend@abc123, frontend@def456 (PROJ-123, PROJ-456)。
  • 触发配置仓库的自定义部署流水线，此时部署记录会关联这条虚拟提交，Jira也能识别消息中的问题键，关联对应的工作记录。
• 优势：完全适配当前Bitbucket和Jira的集成逻辑，无需修改现有仓库结构，团队学习成本低。
• 注意事项：要保证虚拟提交的自动化流程稳定，避免提交冲突或信息遗漏；提前和团队沟通虚拟提交的作用，避免与正常配置变更提交混淆。

3. 调整流水线触发逻辑（备选） #

如果可以调整部署触发方式，可考虑将部署流水线移到后端或前端仓库，手动触发时指定其他仓库的版本。这种情况下，部署记录会关联触发仓库的提交，Jira也能正常关联对应仓库的工作记录，但需要解决多仓库触发部署的协同问题（比如防止同时部署不同版本）——不过这不符合你当前“自定义手动/调度触发”的核心需求，仅作为补充选项。

内容的提问来源于stack exchange，提问作者Dario Seidl