研发团队眼中的 Bitbucket

研发视角

在介绍了 Bitbucket 的一些功能后，我们来看看如何利用 Bitbucket 落实实际工作场景。

由于 Bitbucket 是一个代码托管平台，其主要的使用者是技术类研发人员。无论是开发软件代码、编写测试脚本、搭建运维工具，还是撰写研发文档，都可以充分利用 Bitbucket 所提供的功能。

让我们从研发视角出发，探讨如何使用 Bitbucket。

代码评审

我至今记得刚入行的时候，见到一位研发工程师在进行代码评审，虽然当时我还不太理解他在做的工作的重要性。因为当时的我还没有接触过任何版本控制工具，只是被那个花花绿绿的界面吸引了。

我们曾有一个客户，他们为企业内部提供信息技术支持，他们的负责人非常明白代码评审的重要性。因此，他们一开始就向我们询问在 Bitbucket 中如何进行代码评审。由于代码评审只是一种行为，并没有固定的标准，所以我们进一步了解了他们对代码评审的理解以及他们在代码评审过程中想要实现什么样的协同工作。

对此，客户给出了明确的需求场景：在提交代码合并请求后，首先要保证流水线能够成功执行，且静态代码扫描（使用 SonarQube）的质量达到标准，然后才允许评审人员同意合并。在代码审查过程中，评审员可以添加注释和任务，这里的任务并不需要通过 Jira 进行跟踪，而是起到备忘清单的作用。

这是一个相对常见的代码审查功能需求，只是由于客户之前没有使用过 Bitbucket，所以他们不确定这些功能是否能在 Bitbucket 上有效实现。

客户的研发团队规模不大，在提交代码合并请求时，他们完全可以自主选择审查人员。但这样的无脑操作会让用户觉得有些“傻”，所以工具人学堂的顾问告知可以在 Bitbucket 中配置默认的审查人员，并设定了必须至少有一个评审员进行评审的规则。

由于客户期望代码评审的一个前提是流水线必须被执行成功，所以我们在 Bitbucket 中将 Bamboo 的流水线关联过来。这样一来，在进行代码评审时，评审员可以直接看到对应的流水线执行结果。此外，只需要在 Bitbucket 代码库的左侧点击 Builds 菜单按钮，就可以浏览所有该流水线分支的执行情况，用户不需要跳转到 Bamboo 就能浏览到结果。

对于静态代码扫描质量达标这一审查前提，实际上是通过 Bamboo 流水线执行来获得结果的。虽然在 Bamboo 流水线的设计中，我们已经将使用质量门的结果作为流水线成功与否的判断条件（也就是说，如果流水线执行成功，则扫描结果一定是达标的），但客户仍希望在 Bitbucket 上能有一个显眼的标识。为此，工具人学堂的顾问推荐了一个插件 —— Include Code Quality for Bitbucket。

这个插件的作用是在 Bitbucket 的流水线记录上生成一个显眼的 Sonar 报告质量状态，同时，该插件还能提供一些额外的功能，比如在浏览代码库内容时，页面上也会展示 Sonar 报告的数据。这样，客户就可以更直观地看到代码质量的信息，从而更好地关注代码质量。

分支管理的策略与实践

在版本控制的世界里，分支管理的策略是项目成功与否的关键因素之一。许多团队试图寻找可借鉴的最佳实践，但在 Git Flow、GitHub Flow 以及 GitLab Flow 这三个普遍被接受的工作流程中，没有一个能够成为所有项目的万能钥匙。更别说在各种定制化的工作流中寻找一种通用的解决方案了。

以某个 SaaS 服务商团队为例，他们在初期的阶段，采取的是接近于 Scrum 的方法论，分支管理相对简单。我对此深表赞赏，因为在项目初期，团队规模较小，产品的快速上线以解决实际问题是至关重要的。然而，随着他们的研发人员扩张至两位数，以及软件模块数量的增加，原有的简单的主从分支结构已经无法满足日常的协作需求，更别说在之后引入了 CI/CD 流水线。在方法论上，他们坚持利用 Sprint 进行推进，但实际上，他们关注的重点已经不再像是单纯的 Scrum 了。团队成员的能力增长无法跟上团队规模的扩张，导致他们难以过渡到 LeSS 框架，最终他们选择采用了一些 SAFe 框架的理念。

在这样的背景下，他们选择 GitLab Flow 作为参考的方向。然而，由于战略选择的原因，他们开始提供私有化部署服务，这使得发布/上线的场景变得越发复杂。

虽然工具人学堂的顾问尽可能地简化了工作流，但最终，我们不得不面对多版本维护的现实问题。在早期，他们仍保留了环境分支的习惯，这使得他们必须经历一段思维转换期。

在 Bitbucket 平台上，我们为他们定义了分支的前缀，使得每个分支都能遵守特定的规则，方便匹配到自动化流水线的触发。同时，这也有助于提前确定组织需要的分支名称格式，从而保持分支管理的规范和一致。

需求管理的协同与集成

作为研发人员，他们的主战场往往是代码，因此，Bitbucket 提供的环境相比于 Jira 更为直接且有利。然而，正因为 Bitbucket 和 Atlassian 生态系统的紧密集成，它能够轻松地与 Jira、Confluence、Bamboo 等工具协同工作，实现了全面的项目管理和协作流程。这是 Bitbucket 在其官网中大力宣传并以此为傲的一项能力。

借助 Bitbucket，研发人员可以在其用户界面中直接与 Jira 进行交互，无需跳转到 Jira 平台去查阅需求任务。这种无缝的集成，使得我们在管理代码的同时，能够清晰地理解需求的来源和目标。

对于研发管理者来说，这种集成也同样带来了便利。他们不仅可以在 Jira 界面上查看关于某个 Jira 事务相关的代码提交列表，更可以直接从 Jira 事务创建分支，无需在两个平台之间切换。在创建分支的过程中，系统会自动附带参数，使得事务与分支之间建立了直接联系。这种强关联性大大提高了项目管理的效率，也保证了需求管理的准确性和实时性。

缺陷追踪的深度集成与透明化

同样，Bitbucket 也为缺陷追踪提供了强大的助力。与需求任务一样，我们可以方便地将缺陷与 Bitbucket 的每次提交产生强关联。除了在代码提交时的备注，使得每次提交与缺陷记录保持关联外，我们还可以直接在缺陷记录上点击按钮，一键生成相应的分支。

Bitbucket 与 Jira 的深度集成，使得缺陷追踪变得前所未有的轻松。开发者可以直接在 Bitbucket 中查看和更新与代码相关的缺陷问题，同时在 Jira 中也可以查看到与缺陷相关的代码提交和拉取请求信息。这种双向的透明度，让整个团队在开发过程中都能看到问题的来源，当前的状态，以及解决的进度。这样的流程不仅保持了团队的高效，更提高了代码质量和项目的稳定性。

在这种工作模式下，缺陷追踪和分支管理相互辉映，形成了一种有序且高效的推进机制。每一个缺陷都被当作一个单独的任务来处理，每一个任务都有明确的归属和进度。这种透明度和效率，是 Bitbucket 与 Atlassian 生态系统深度集成带来的独特优势。