📚 课程目录第2章 Atlassian工具链全景

2. Atlassian工具链全景

Atlassian 工具链并不是一组彼此独立的软件，而是一条围绕“需求—设计—代码—构建—部署—反馈”的研发协同链路。理解这条链路的关键，不是记住每个产品的功能清单，而是看清每个工具在协同中承担什么角色、彼此通过什么对象和事件连接。Jira 管理“要做什么”，Confluence 沉淀“为什么这样做”，Bitbucket 承载“代码怎么改”，Bamboo 与 Pipelines 负责“改完如何验证并交付”。

一、五个核心工具的协同定位

Jira 是需求与缺陷的单一事实来源。它用 Issue 作为最小工作单元，通过 Issue Type（Story、Task、Bug、Epic）、Status、Sprint、Board 把工作拆解、排序和跟踪。Jira 的价值不在于记录任务，而在于让“谁在做什么、做到哪一步、依赖谁”变得可见。

Confluence 是团队知识库。需求背景、技术方案、接口约定、会议决策、复盘记录都沉淀在这里。它与 Jira 的集成方式很直接：Jira Issue 中可以嵌入 Confluence 页面，Confluence 页面也可以插入 Jira Issue 列表或单个 Issue 卡片，从而让“任务”和“上下文”互相引用。

Bitbucket 是代码托管与评审平台。它管理 Git 仓库、分支、Pull Request（PR）和代码评审意见。Bitbucket 与 Jira 的集成是整条链路中最关键的一环：提交信息或分支名中带上 Jira Issue Key（如 PROJ-123），Jira 就会自动关联该提交和 PR；PR 合并后，Jira Issue 可以自动流转状态。

Bamboo 是 Atlassian 传统的持续集成/持续交付服务器，适合需要复杂构建计划、部署项目、权限隔离和本地化部署的团队。它通过 Build Plan、Stage、Job、Task 组织构建流程，并与 Bitbucket 仓库、Jira Issue 深度集成。

Bitbucket Pipelines 是内置于 Bitbucket 的 CI/CD 能力，用 bitbucket-pipelines.yml 定义流水线，适合希望“代码仓库即流水线入口”的团队。它与 Bamboo 的定位差异在于：Pipelines 更轻量、更贴近仓库；Bamboo 更重、更适合复杂发布编排。

二、集成关系：对象与事件如何流动

工具链的集成不是简单的“互相能打开”，而是围绕几个关键对象建立双向引用：

Jira Issue Key：贯穿提交、分支、PR、构建、部署记录，是跨工具追溯的主键。
Confluence Page：作为需求或方案上下文，被 Jira Issue 引用，也可反向展示 Issue 状态。
Bitbucket Commit / PR：代码变更的载体，携带 Issue Key 后自动回写 Jira 开发面板。
Build / Deployment：Bamboo 或 Pipelines 的执行结果，可关联到具体 Commit 和 Issue，形成“代码—构建—环境”的链路。

下面这张图展示了五个工具在研发协同中的定位与主要集成关系。图中实线表示强集成（自动关联或状态回写），虚线表示引用或展示关系。

三、实际配置：让集成真正生效

工具链集成不是安装后自动完成的，需要几个关键配置动作。以下以 Bitbucket 与 Jira 的集成为例，说明实际配置过程。

首先，在 Bitbucket 仓库中启用 Jira 集成。进入仓库设置，找到 Integrations → Jira，绑定对应的 Jira 站点和项目。绑定后，Bitbucket 会识别提交信息和分支名中的 Issue Key。

其次，约定分支命名规范。推荐使用 feature/PROJ-123-short-description 或 bugfix/PROJ-456-fix-login。这样在创建 PR 时，Bitbucket 会自动把 PR 关联到对应 Jira Issue，并在 Jira 的“开发”面板中显示分支、提交和 PR 状态。

再次，配置 PR 合并后的状态回写。在 Jira 项目设置中，启用 Development Tools 集成，并设置智能提交（Smart Commits）规则。例如，在提交信息中写 PROJ-123 #comment 修复登录超时 #time 2h #close，Jira 会自动添加评论、记录工时并关闭 Issue。

最后，配置 CI/CD 触发。如果使用 Pipelines，在仓库根目录创建 bitbucket-pipelines.yml，示例如下：

pipelines:
  branches:
    feature/*:
      - step:
          name: Build and Test
          image: maven:3.9-eclipse-temurin-17
          script:
            - mvn -B clean verify
    main:
      - step:
          name: Build and Deploy
          image: maven:3.9-eclipse-temurin-17
          script:
            - mvn -B clean package
            - echo "Deploy to staging"
          deployment: staging

这段配置的含义是：feature/* 分支推送时执行构建和测试；main 分支推送时执行打包并部署到 staging 环境。Pipelines 会自动把构建结果关联到触发它的 Commit 和 PR，进而关联到 Jira Issue。

四、Bamboo 与 Pipelines 的选择判断

两者都能做 CI/CD，但适用场景不同。可以用以下判断依据：

判断维度	Bitbucket Pipelines	Bamboo
部署方式	SaaS，配置在仓库内	支持本地化部署
配置方式	YAML 文件，随代码版本化	Web UI + Plan 配置
复杂发布编排	适合中小型流水线	适合多阶段、多环境、审批发布
权限与隔离	依赖 Bitbucket 权限	独立权限体系，适合强隔离
典型团队	希望快速接入、仓库即流水线	需要复杂构建计划与本地化控制

实际项目中，两者可以并存：Pipelines 负责日常功能分支的快速验证，Bamboo 负责正式版本的复杂发布编排。关键是不要让两套流水线产生冲突，建议明确“哪类分支走哪条流水线”，并在 Jira Issue 中记录最终部署环境与版本号。

五、协同落地的关键检查点

要让工具链真正支撑研发协同，而不是变成“工具堆砌”，需要检查以下几点：

Issue Key 是否贯穿全链路：从分支、提交、PR 到构建、部署，是否都能追溯到同一个 Jira Issue。
Confluence 是否与 Jira 双向引用：需求页面是否链接到 Issue，Issue 是否回链到方案页面。
PR 是否强制关联 Issue：可以通过 Bitbucket 的合并检查（Merge Checks）要求 PR 必须关联 Jira Issue 才能合并。
构建结果是否回写 Jira：Jira 开发面板中能否看到构建和部署状态，而不是只看到代码提交。
权限与可见性是否匹配团队结构：Confluence 空间权限、Bitbucket 仓库权限、Jira 项目权限是否一致，避免信息孤岛或越权访问。

建议在项目启动时先打通“Jira + Bitbucket + Pipelines”这条最小链路，再根据发布复杂度引入 Bamboo 和 Confluence 的深度集成。链路越短，越容易验证集成是否真正生效。

总结来看，Atlassian 工具链的协同本质是“以 Jira Issue 为追溯主键，以 Bitbucket 为代码变更载体，以 Confluence 为上下文沉淀，以 Bamboo/Pipelines 为验证与交付通道”。理解每个工具的定位和它们之间的对象流动关系，比单独掌握某个工具的操作更重要。只有让 Issue Key、Commit、PR、Build、Deploy 形成闭环，研发协同才真正可追溯、可验证、可改进。