从更广的视角看待 Bitbucket

更广的视角

随着中国软件从业人员能力的整体提升，现在已经不仅仅是开发工程师才会使用到版本控制工具。无论是测试工程师，还是运维交付人员，都会有不少高效的自动化设计与辅助工具；甚至，越来越多的非技术人员也开始利用版本控制工具辅助自己的工作。

虽然 Bitbucket 在设计初期并未针对这些人员，但是，当大家发现其实 Bitbucket 具有足够的灵活性和强大的功能，能适应各种不同的工作场景。越来越多的人开始发现并利用这类工具的妙用，代码托管平台自然受到了广泛的欢迎和使用。

例如，测试工程师可以使用 Bitbucket 来管理测试脚本的版本，并通过与 Jira 等工具的集成，方便地追踪和管理测试任务。运维交付人员可以利用 Bitbucket 来维护和管理配置文件，通过自动化流水线实现配置的快速部署和更新。非技术人员，如项目经理，产品经理等，也可以利用 Bitbucket 来管理文档，追踪文档的更改历史，方便地进行版本比较和回滚。

所以，无论你的角色是什么，无论你的工作内容是什么，Bitbucket 都可能成为你的得力助手，帮助你提高工作效率，确保工作质量。

持续集成与自动化测试：向 Bitbucket 与 Bamboo 的组合看齐

过去，持续集成主要是一些 CI/CD 工具的领域，比如 Jenkins、Bamboo 等。如今，无论是 GitHub 还是 GitLab 都已经内置了流水线功能，尽管仍需要额外部署 Runner 以支持流水线服务。对于 Bitbucket 本地版本，由于原本就支持自家生态产品 Bamboo 的集成，因此在该方面并没有过多改动。

Bitbucket Cloud 版支持云端的流水线，其使用方式与 GitHub 和 GitLab 十分相似，都是一个随软件代码一同存放的 yml 文件，虽然这种方式有利也有弊。一方面，它意味着软件开发的同事需要来编辑这个流水线配置/模版文件，或者是需要一个负责流水线工作的成员拥有这些软件代码仓库的权限，这在企业内部，可能会产生一些权限划分的问题。但另一方面，这种方式对于小型、敏捷的团队却十分友好，尤其是那些研发人员能够全栈工作的团队，他们可以仅通过在代码库中编写代码的方式就完成一系列的工作，极大地提高了工作效率。

工具人学堂的顾问曾接触过一个创业团队，他们在使用 yml 文件作为自动化集成方式时，遇到了一些混乱的状况。由于团队中并不是每个人都能全栈工作，因此他们在使用这种方式时，总是无法规范和统一流水线，也无法集中化管理和查看，自动化测试更是成了持续集成之外的存在。

实际上，许多团队都期望流水线是一条从头到尾的线，即代码提交、编译、单元测试、扫描、构建发布、集成测试、部署上线。然而，真实情况并非如此。例如只看构建发布、集成测试、部署上线这三个步骤，他们并不是顺序完成的，而是存在一种交叉关系。如果涉及到多服务、多代码库、多环境，持续集成的关系图谱将会复杂得难以描述。

因此，工具人学堂的顾问建议他们尝试把持续集成从代码库中独立出来，交给 Bamboo 这样的 CI/CD 工具进行统一维护。同时，自动化测试代码也可以保存在 Bitbucket 的一个独立代码库中，以便与软件产品代码库进行更灵活的交互。这样不仅可以解决他们目前面临的问题，也能在更大程度上提升他们的工作效率和项目管理的清晰度。

部署模板及工具：从混乱到有序的转变

运维或测试人员经常会使用一些自研的小工具，这些工具的使用效果通常优于市场上的通用产品，这是因为这些工具针对特定的工作场景进行了优化。因此，如果你在工作中编写了一些有用的小工具，不妨将它们推送到 Bitbucket 这样的平台上。这样一来，你可以与同事分享这些工具，二来，别人可能会对你的工具提出改进意见，这对于你的成长来说是非常有价值的。

我接触过一个刚刚转向 Kubernetes 的团队，他们编写了很多部署 YAML 文件，每个环境都有各自的文件集。在初期，这种方式并没有造成太大的困扰，但随着部署环境的增多和产品版本的迭代，他们发现维护这些文件变得越来越麻烦。每次产品发布，他们都需要对每个环境的众多 YAML 部署文件进行逐行检查和修改。

这并不是因为该团队的技术实力不足，而是因为他们刚刚转向 Kubernetes，对于 Kubernetes 的应用场景还不够了解，因此在交付方式上的思路也相对不够灵活。

在这个时候，工具人学堂的顾问鼓励他们的交付工程师把这些 YAML 文件拿出来进行分析，并勇于向开发团队提出需求，然后提取出可以使用部署变量的地方，并将 YAML 部署文件提取为 YAML 部署模板，然后在 Bitbucket 上进行管理和发布。

最后，交付工程师只需要维护一套部署模板，然后使用他们自己编写的渲染工具，结合环境信息生成部署文件并部署到不同的环境。没过多久，他们就把这个工具也集成到了交付代码库，成为了部署发布产出物的组成部分。

这种方式与开发软件的过程非常类似，不仅大大减轻了交付工程师在部署上线方面的工作负担，而且因为使用了 Bitbucket 这样的版本控制托管平台，使得每次产品迭代导致的部署模板变更都能够被追踪和查证。甚至，部署模板的发布过程也引入了开发工程师和测试工程师的代码评审环节。

文档管理：Markdown 的优势

一般来说，我们会建议将各类文档放在 Confluence 上，但大多数程序员本能地对写文档有所抗拒，然而他们却可以接受在代码库中使用 Markdown 写一些文字。

有一个需要直接面对终端客户的研发团队，他们的公共知识库中的内容几乎涵盖了开发、测试、运维各个角色。他们尝试使用 Confluence 来编写文档，但发现由于每个人对 Confluence 的掌握程度不同，导致文档的格式都无法统一，工程师们也不习惯在一个在线的富文本编辑器中编写文档。

简洁而实用的 Markdown 最终成为他们的选择，并且他们选择在 Bitbucket 中进行管理和维护。虽然从美观度上来说，Markdown 不如 Confluence 的富文本页面，但这使得所有的角色都能够持续地输出文档。

这种方法并不适用于每一个团队，但对于小型的研发团队，他们的人力和资源都有限，因此，他们可以尝试在 Bitbucket 这样的代码托管平台上写文档。通过这种方式，他们可以节省资源，同时也可以提高团队的效率。