Atlassian-DevOps-工具链秘籍-全-

Atlassian DevOps 工具链秘籍（全）

原文：annas-archive.org/md5/64bf7cd6c3359a09ef842c176aff0fda

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

DevOps 作为一种运动要求团队中的人员检查和改变他们工作和互动的三个方面：人员、流程和工具。人员的变化可能包括组织结构或文化的变化。流程变化可能包括引入精益思想中的实践，以确保持续交付。工具的变化则通过自动化实现更快的周转。

Atlassian 生产的工具无疑能帮助我们的团队改进流程并促进自动化。像 Jira 和 Confluence 这样的关键工具让团队能够建立促进敏捷和精益思想的标准流程。通过引入 Bitbucket Pipelines，Bitbucket Cloud 不仅促进了版本控制，还通过自动化实现了持续集成和持续部署。

但 Atlassian 工具的标志性特点不是工具本身，而是它们能与彼此以及其他不同制造商的工具轻松连接的能力。Atlassian 的 Open DevOps 平台提供了创建轻松互联的能力，无论供应商是谁。

本书的重点不是任何单一的 Atlassian 产品，如 Jira 或 Confluence。相反，本书旨在突出 Atlassian 工具与其他 Atlassian 工具或其他开发工具（如 GitLab、GitHub、Snyk 和 LaunchDarkly）之间的轻松互联。希望通过阅读本书，您能将 Atlassian 的投资与其他投资结合起来，创建一个强大的工具链。

我们假设您组织当前使用的工具包括 Atlassian 和其他供应商的工具。因此，我们不建议按顺序阅读本书。我们认为本书的最佳使用方式是阅读与连接您工具相关的章节，而无需担心创建一个仅由 Atlassian 工具构成的技术栈。这些渐进式的变化遵循精益方法，是采用 DevOps 的关键。

本书的食谱以在第十三章中展示的理想 DevOps 工具链示例结束。虽然示例主要使用 Atlassian 工具，但它可以由任何组合的工具构成。

本书适用对象

本书面向 Atlassian 工具和 DevOps、DevSecOps 实践者（如开发人员和网站可靠性工程师）的管理员。管理员需要了解如何创建团队结构，如 Jira 项目、Confluence 空间和 Bitbucket 工作区。

本书内容

第一章，DevOps 和 Atlassian 生态系统简介，简要介绍了 DevOps 的历史，并展示了如何从 Jira 安装 Open DevOps 或其他 Atlassian 工具的步骤。

第二章，通过 Jira 产品发现发掘客户需求，介绍了 Jira 产品发现功能，帮助产品经理开发并优先考虑产品和功能的种子，直到它们准备好由团队开发。

第三章, 通过 Confluence 进行规划和文档管理，展示了将 Jira 与 Confluence 连接的功能，以实现最新的报告和文档。

第四章, 为设计、源代码管理和持续集成启用连接，包含将 Jira 与其他源代码管理和持续集成工具连接的示例。

第五章, 理解 Bitbucket 和 Bitbucket Pipelines，介绍了 Bitbucket Cloud。我们查看了源代码管理功能，并对 Bitbucket Pipelines 进行了初步介绍。

第六章, 扩展和执行 Bitbucket Pipelines，继续探索 Bitbucket Pipelines，了解如何创建和编辑其主要控制文件bitbucket-``pipelines``.yml。

第七章, 利用测试用例管理和安全工具进行 DevSecOps，演示了如何连接到测试和安全扫描工具，并介绍了 DevSecOps 的概念。

第八章, 通过 Bitbucket Pipelines 进行部署，探讨了如何使用 Bitbucket Pipelines 配置持续部署。我们展示了多个环境的部署示例。

第九章, 利用 Docker 和 Kubernetes 进行高级配置，展示了 Bitbucket Pipelines 如何利用 Docker 和 Kubernetes 来辅助构建和部署。

第十章, 通过持续部署和可观测性与运维团队协作，探讨了如何将 Jira 与提供持续部署和监控的工具连接。

第十一章, 通过 CheckOps 在 Compass 中监控组件活动和指标，介绍了一个新的 Atlassian 工具 Compass，用于收集和监控部署和事件信息，以衡量项目组件在 CheckOps 这一学科中的健康状况。

第十二章, 通过 Opsgenie 警报进行升级，演示了如何使用 Opsgenie，当事件发生时，团队可以协作处理。

第十三章, 通过一个真实世界的示例整合所有内容，将你从前面章节学到的所有内容结合起来，展示 DevOps 工具链是如何运作的。

第十四章**, 附录 – 关键要点和 Atlassian DevOps 工具的未来，以展望未来为结尾，并提供了其他入门建议，帮助你开始 DevOps 之旅。

为了从本书中获得最大的收益

工具管理员需要知道如何在 Jira 中创建项目；在 Confluence 中创建空间；以及在 Bitbucket 中创建工作区、项目和代码库。

Jira 用户需要知道如何创建问题。

Confluence 用户需要知道如何创建页面。

使用 Bitbucket 和其他 Git 服务器工具（如 GitLab 和 GitHub）的用户需要了解如何在 Git 中执行提交以及在他们选择的 Git 服务器工具中进行拉取请求/合并请求。

尽管我们讨论的 Atlassian 工具是基于云的、软件即服务（SaaS）应用程序，但某些操作或功能需要外部资源。我们在下表中概述了这些外部资源：

书中涵盖的操作/功能	外部 资源要求
连接到 Moqups（第四章）	Moqups 账户
连接到 Figma（第四章）	Figma 账户
连接到 GitLab（第四章和第十章）	GitLab 账户
连接到 GitHub（第四章）	GitHub 账户
连接到 Jenkins（第四章）	Jenkins 服务器
连接到 CircleCI（第四章）	CircleCI 账户
Bitbucket 运行器 – 自托管（第六章）	Windows、macOS 或 Linux 机器
连接到 Snyk（第七章和第十三章）	Snyk 账户
使用 JFrog CLI 部署到 JFrog	JFrog 环境中的账户
部署到 Sonatype Nexus	Nexus 环境中的账户
部署到 AWS S3（第八章）	拥有适当角色的 AWS 账户
部署到 Google Cloud（第八章）	拥有适当权限的 Google Cloud Platform 账户
部署到 Microsoft Azure（第八章）	拥有适当权限的 Azure 账户
连接到监控工具（第十章）	Datadog 账户

如果你使用的是本书的数字版，我们建议你亲自输入代码或通过 GitHub 仓库访问代码（下节中提供链接）。这样做将帮助你避免与复制和粘贴代码相关的潜在错误。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，网址为 github.com/PacktPublishing/Atlassian-DevOps-Toolchain-Cookbook。如果代码有更新，GitHub 上的现有仓库也会进行更新。

我们还有来自我们丰富书籍和视频目录的其他代码包， 可以在 github.com/PacktPublishing/ 上查看！不要错过！

使用的约定

本书中使用了许多文本约定。

文本中的代码：指文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。例如：“在页面上，在搜索栏中键入 Jira report。”

一段代码的设置如下：

      pipelines: 
        default: 
          - step: 
            script: 
             - echo "Running a command"

任何命令行输入或输出都按如下方式编写：

kubectl run <my.app> --labels="app=<my.app>" --image=<my.dockerhub.username>/<my.app>:latest --replicas=2 --port=8080

粗体：表示新术语、重要词汇或你在屏幕上看到的单词。例如，菜单或对话框中的词汇会以这种方式显示在文本中。这里有一个例子：“选择 Insights 查看其他来源的链接，或通过点击 Create an insight 按钮自行创建这样的链接。”

提示或重要说明

如下所示。

章节

本书中有几个常见的标题（准备开始、如何操作...、原理解析...、还有更多... 和 另见）。

为了给出清晰的操作步骤，可以按如下方式使用这些部分。

准备开始

本节告诉你该在食谱中期待什么，并描述如何设置所需的软件或任何初步配置。

如何操作…

本节包含完成食谱所需的步骤。

原理解析…

本节通常会详细解释上一节发生的内容。

还有更多…

本节提供关于食谱的更多信息，帮助你更深入了解食谱内容。

另见

本节提供指向其他有用信息的链接，供食谱参考。

与我们联系

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请在邮件主题中提及书名，并通过 customercare@packtpub.com 给我们发送邮件。

勘误：虽然我们已尽力确保内容的准确性，但难免会有错误。如果你发现本书中的任何错误，请向我们报告。请访问 www.packtpub.com/support/errata，选择你的书籍，点击勘误提交表单链接，并填写相关信息。

盗版：如果你在互联网上发现任何非法的我们的作品副本，我们将不胜感激，如果你能提供该地址或网站名称。请通过 copyright@packtpub.com 联系我们，并附上相关链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有意写书或为书籍贡献内容，请访问 authors.packtpub.com。

分享你的想法

阅读完 Atlassian DevOps 工具链食谱 后，我们希望听到你的想法！请 点击这里直接访问亚马逊评论页面，分享你的反馈。

你的评论对我们和技术社区都非常重要，能帮助我们确保提供优质的内容。

下载本书的免费 PDF 版

感谢购买本书！

喜欢随时随地阅读，但无法携带纸质书籍？

你的电子书购买无法在你选择的设备上使用？

不用担心，现在每本 Packt 书籍都可以免费获得该书的无 DRM PDF 版本。

随时随地，在任何设备上阅读。可以从你最喜欢的技术书籍中搜索、复制并粘贴代码，直接应用到你的项目中。

优惠不仅仅是这些，你还可以每天通过邮箱独家获得折扣、新闻通讯和丰富的免费内容。

按照以下简单步骤即可获得好处：

1. 扫描二维码或访问以下链接

packt.link/free-ebook/978-1-83546-378-9

1. 提交您的购买凭证

2. 就这些！我们将直接通过电子邮件发送您的免费 PDF 和其他福利

第一部分：开始循环

本书全面探索了 DevOps 及其工具的适配问题。特别关注的是 Atlassian 工具如何与彼此以及其他厂商的工具进行连接。

我们通过了解为何需要这种方法的背景和背景，设定了探索 DevOps 和工具链的舞台。一旦我们发现了 DevOps 的“为什么”，我们就将注意力转向 Jira 及其通过 Open DevOps 平台可以建立的连接。我们发现如何配置 Jira，以便通过该平台与其他工具连接。

在任何实施开始之前，开发人员需要与产品经理、利益相关者，甚至客户合作，确定新产品的需求、可行性和可行性。Jira Product Discovery 帮助确定哪些想法应该付诸实践，通过提供一个收集、跟踪、阐述和比较不同产品和特性想法的位置来辅助这一过程。那些准备好的想法可以与 Jira 问题链接，以监控开发进度。

在我们开始开发时，需要规划我们的工作，并确保我们的努力在正确的轨道上。同时，我们还需要确保开发工作与产品的整体大局及其价值承诺相连。为此，我们将 Jira 与 Confluence 连接，以便 Confluence 能够提供必要的项目文档。

本部分包含以下章节：

• 第一章**， DevOps 介绍及 Atlassian 生态系统概述

• 第二章**，通过 Jira Product Discovery 发现客户需求

• 第三章**， 使用 Confluence 进行规划和文档管理

第一章：DevOps 和 Atlassian 生态系统介绍

自 2009 年 DevOps 诞生以来，已经成为推动产品开发改进的主要力量。随着技术转向基于互联网的云环境，DevOps 使得开发和运营人员能够合作，从而更快且更稳定地进行设计、打包、部署和维护产品。自动化的采用是这一过程顺利进行的关键因素。

本章将探讨 DevOps 运动及其成功中自动化所扮演的角色。接着，我们将了解 Open DevOps 平台，这个平台由 Atlassian 提供，能够轻松连接 Jira、其他 Atlassian 工具，如 Confluence 和 Bitbucket，以及第三方工具，如 LaunchDarkly，它通过功能标记帮助你发布产品，以及 Snyk，它进行安全扫描。

为了开始我们的 Open DevOps 之旅，我们将研究如何注册到 Atlassian 的云环境中，以便获取 Jira 的试用版本以及通过 Open DevOps 进行连接。为此，我们将涵盖以下步骤：

• 从零开始创建 Open DevOps 工具链

• 仅创建带有 Jira 的新的 Atlassian Cloud 站点

• 创建 Jira 项目

• 连接 Confluence

• 连接 Bitbucket

DevOps 介绍

到 2009 年，开发人员开始采用敏捷产品开发方法。他们从小规模交付的增量周期开始，收集客户反馈并利用这些反馈指导未来的开发周期。逐步打造出客户所需的产品。

一个瓶颈很快就会出现在向组织运营部分交付变更时。虽然开发团队的优先任务是快速开发价值，运营团队则负责维护环境的稳定性。任何可能削弱稳定性的因素都会导致潜在的收入损失。通常，这意味着将任何新变更视为有风险，并允许在特定的维护窗口期发布变更。这些窗口期最终只会增加进一步停机的风险。

很快，变化就会出现。在O'Reilly Velocity 2009 大会上，Flickr 的 John Allspaw 和 Paul Hammond 进行了题为“每天 10+次部署——Flickr 的开发与运维合作”的演讲，讲述了他们如何在一天内进行多次部署，而许多组织在一年内都难以进行一次部署的做法。Patrick Debois 在观看了上述演讲以及其他关于开发与运维合作重要性的演讲后，受到了启发，并在与 Andrew Schafer 去年谈话后对敏捷系统管理产生了兴趣，决定在比利时根特组织一个会议来讨论这个话题。为了强调这一需求，Debois 将开发和运维的常用缩写合并，并将其用作会议名称——DevOpsDays。

第一个 DevOpsDays 大会的势头延续到了社交媒体。讨论在 Twitter（现称为 X）上继续进行，话题通过标签#DevOps被标识出来。随后，世界各地组织了更多的 DevOpsDays 大会。这一运动引起了 Gartner 的关注，Gartner 在 2011 年预测 DevOps 将很快被企业采用。这确保了 DevOps 从一个地下运动转变为一种主流理念，在企业中实施。

现在，开发和运维之间的协作已经显现出好处，并证明了其受欢迎程度，关键问题之一是如何开始成功的 DevOps 实施。接下来的部分将介绍这一方法的关键模型。

CALMS/CALMR 方法

为了准备2010 年 DevOpsDays 大会，John Willis 和 Damon Edwards 被问到了一个关于新兴 DevOps 运动的相同问题——我们如何实施 DevOps？换句话说，成功实施 DevOps 的关键因素是什么？

他们想出了一个首字母缩略词，CAMS，其中每个字母代表成功 DevOps 方法的一个关键组成部分。C代表文化，A代表自动化，M代表度量，S代表共享。

在撰写《DevOps 手册》时，Jez Humble 详细阐述了 CAMS 模型。他增加了一个L，代表Lean（精益）。有了这个补充，CAMS 变成了CALMS。

当 Scaled Agile Inc.将 DevOps 引入Scaled Agile 框架（SAFe）时，修改了这一方法。考虑到理想的 DevOps 文化是共享责任，Scaled Agile 将 S（共享）移除，替换为R，代表恢复。在 SAFe 中实践 DevOps 时，CALMS 变成了CALMR。

让我们来看看 CALMS 和 CALMR 方法的每个字母，看看它们如何与 Atlassian 工具的采用以及 Open DevOps 平台的实施相结合。

文化

管理专家彼得·德鲁克被认为曾经说过，“文化在早餐时吞噬战略”，强调了作为共同纽带的文化对于团结群体中个体的影响，无论是小到团队，大到国家。因此，如果正确的文化可以推动组织实现期望的结果，那么什么是正确的文化？为了找到答案，我们转向了社会学家罗恩·韦斯特鲁姆。

1988 年，罗恩·韦斯特鲁姆组织了一项研究来衡量医疗团队的安全性。他将团队分为三种不同类型的文化：

• 病态的

• 官僚主义的

• 生成型

病态文化是一种由领导主导的文化。主要通过领导者对完成（领导者的）目标的恐惧和威胁来驱动动机。

官僚文化通过规则和标准具有安全机制，但这些机制可以用来保护团体成员免受外部人员的侵害。

相反，生成型文化侧重于与共同使命的对齐。信息可以自由与任何人分享，无论他们是否是团体的成员，无论他们是否能在使命的成功中发挥作用。

韦斯特鲁姆在其初步研究中发现，拥有生成型文化的医疗团队还与其使命保持一致，意识到阻碍使命的事物，并授权任何个体进行改变以消除这些障碍。这使得组织能够轻松地对系统进行持久改进，进一步改善团队。

这些好处并不局限于医疗团队。在《加速 - 建立和扩展高效技术组织》一书中，尼科尔·福斯格伦、杰兹·汉布尔和吉恩·金调查了向团队推荐 DevOps 实践的效果。他们调查了开发团队，并发现那些拥有生成型文化的团队在软件交付方面表现出更高的性能水平，并体验到更高的工作满意度。

文化的改变虽然可能，但通常是在结构和行为改变之后发生的最后一次改变。Atlassian 确实提供了工具，帮助改变结构和行为以将团队转向生成型文化。这些支持文化变革的工具可作为 Team Playbook 免费提供（www.atlassian.com/team-playbook）。然而，详细介绍这些工具超出了本书的范围。

自动化

当人们想到 DevOps 时，首先想到的是自动化。在 O’Reilly Velocity 2009 年会议上 Allspaw 和 Hammond 发表的讲话中，成功的关键因素之一包括使用自动化基础设施和统一的版本控制系统来支持开发和运营。

当今，关键的自动化是通过成功地将工具连接在一起形成工具链来完成的。开发和运营中的每个活动都至少与一个工具相关联。

显示开发活动与关联 Atlassian 工具的图示如下：

图 1.1 – DevOps 阶段与 Atlassian 工具

本书将在各章节中展示如何使用前面图示的 Atlassian 工具建立工具链。

精益

由自动化创建的系统只有在其需求不超过其容量时才能正常运行。为了确保这一平衡，我们将应用最初作为丰田生产系统一部分开发的精益思维实践。包括以下做法：

• 使所有工作可见

• 限制在制品（Work-in-Progress）（WIP）

• 保持小批量工作

• 监控队列

我们将从排队理论中看到工作规模（队列长度）、处理工作所需的时间（周期时间）以及直到我们看到结果所需的等待时间之间的关系。这里的关键公式是小李法则，如下所示：

L表示队列长度。希腊字母lambda表示团队处理工作的吞吐量。W表示已完成工作的等待时间。

另一个公式——金曼公式告诉我们，周期时间、利用率和团队必须完成的工作项的变异性之间有直接关联。这个公式（通常称为VUT 公式）如下所示：

在这个公式中，E(W)表示等待时间。它被视为变异性（V）、利用率（U）和周期时间（T）的乘积。

Jira 具有功能，可以通过看板展示待办工作，同时允许我们通过列约束限制在制品（WIP）。等待时间和周期时间也可以从收集的度量中计算得出。

测量

在评估我们开发、发布和维护产品的努力是否有效时，我们需要提出三个关键问题：

• 我们是否在按计划交付解决方案？

• 我们所有操作环境（测试、阶段、生产）的健康状况如何？

• 我们的客户是否认为我们已经开发出了正确的解决方案？

在上一节我们探讨精益实践时，发现我们需要关注以下指标来评估我们是否处于流动状态：

• 周期时间

• 在制品（WIP）

• 吞吐量

• 任何阻碍进展的障碍或瓶颈

在查看操作环境的状态时，我们转向可观察性的学科，其中我们收集从基础设施到应用程序的所有环境方面。可观察性的典型度量包括以下内容：

• 日志

• 调用/执行跟踪

• 指标

测量值，可能表明我们的客户是否从新产品功能中获得了预期的价值，这一点可能很难确定。存在虚荣指标，这些指标自然出现并显示良好的趋势，但经过彻底分析后，它们并不提供可操作的答案。经过验证的、能可靠测量客户情绪的指标包括以下内容：

• 海盗指标（获取、激活、留存、推荐和收入），由 Dave McClure 提出，用于观察理想客户对某个产品或功能的行为，并对该行为进行度量

• Google HEART 指标，由 Google UI/UX 团队使用，用于衡量用户在幸福感、参与度、采用率、留存率和任务成功等方面的偏好

• 适合目的 (F4P)由 David J. Anderson 和 Alexei Zheglov 提出，用来衡量是否满足客户需求，具体内容见于书籍Fit for Purpose – How Modern Businesses Find, Satisfy, and Keep Customers。

Atlassian 应用程序可以收集所需的指标，或轻松与专门的指标收集工具集成。Jira 是一个经过验证的平台，可以收集精益所需的指标。开箱即用的报告以及第三方市场应用的轻松应用，允许我们收集和分析所需的指标。Open DevOps 允许与 Datadog 和 New Relic 等可观察性工具进行轻松集成。

共享

一旦我们收集了这些测量值，我们需要一种简便的方法来展示信息，以便所有需要的人都能看到，促进创造性的文化。

本书中描述的 Atlassian 工具为促进信息共享和透明度提供了良好的基础。Jira 可以生成可以共享在仪表板上的图表和报告。与应用程序健康相关的其他显示内容可以使用 Compass 收集并展示。

恢复

在任何 DevOps 实施中，我们都希望花时间和精力规划应急步骤，以防发布导致生产环境出现故障。DevOps 改变了操作模型，开发和运维，无论是共同工作还是与专门的站点可靠性工程师合作，都必须共同回答以下问题：

• 我们如何在发布时降低风险？

• 如果发生故障，应该设计哪些缓解措施以限制停机时间？

• 如果发生故障，我们应该遵循哪些程序？

Atlassian 工具可能是这些问题的解决方案。像 LaunchDarkly 提供的功能标志工具，可以通过 Open DevOps 与 Jira 轻松集成。Compass 提供早期预警功能，以便在故障即将发生时发出警告。Opsgenie 允许开发和运维在故障期间协作，以迅速解决问题。

我们已经了解了 DevOps 方法的关键支柱，以及 Atlassian 工具如何帮助推动这些支柱。在接下来的部分，让我们探讨可能影响 DevOps 实施的技术，以及 Atlassian 工具如何提供帮助。

DevOps 的技术考虑

随着新兴技术的发展，DevOps 方法的采纳变得更加容易，这些技术使得产品的部署、发布和维护更加快捷。技术的变化包括以下几点：

• 持续集成/持续交付（CI/CD）管道

• 基础设施即代码（IaC）

• 云环境

• 容器/Kubernetes

让我们仔细看看这些因素。

CI/CD 管道

在 Allspaw 和 Hammond 于 2009 年 O'Reilly Velocity 大会上的演讲时，CI 工具通常用于生成 每日 构建，或者是汇集当天提交的代码的构建。在创建构建后，CI 工具会运行自动化测试，并报告该操作的成功或失败。

Allspaw 和 Hammond 将他们的 CI 工具进一步扩展。如果构建通过了所有测试，CI 工具将允许将构建产物移到测试或预生产环境进行进一步测试，或者移到生产环境以准备发布或 上线。

持续集成（CI）的扩展被称为持续交付（CD）。通过使用 CI/CD 工具自动化部署，可以确保部署的一致性，因为步骤不会被遗忘或跳过。部署测试进一步确保了功能的正确性，以及观察到的行为是期望的行为。

随着工具的发展，从仅仅是自动化构建到将 CI 和 CD 的所有步骤整合为一个触发器，版本控制工具开始提供自己的管道功能，这些功能由一个 YAML （YAML 不是标记语言）格式的文本文件控制。这促进了一种叫做 GitOps 的小型运动，在这种运动中，构建、测试、集成、打包和部署都从一个 Git 提交作为触发器开始。

基础设施即代码（IaC）

随着 CI 扩展到包括 CD，部署到环境变得更加简便。像 Ansible、Chef、Terraform 和 Puppet 这样的新工具使得可以通过文本文件来定义理想的基础设施。

通过使用文本文件作为输入来运行基础设施工具，将有一种一致的方式来创建环境，无论它们是用于测试、预生产还是生产。这种一致性有助于保持环境的相似性，确保无论使用哪个环境，都能得到相同的测试结果，并防止配置漂移——当环境不相似时，问题就会出现。

云环境

虽然 CI/CD 管道和 IaC 工具可以应用于许多物理平台，从后来被称为 物联网（IoT）的网络物理系统到物理服务器，DevOps 的成功最紧密地与云环境的兴起联系在一起。

云环境是通过供应商提供的虚拟机创建的，并可通过互联网访问。虚拟机的创建和销毁可以在几分钟内完成，允许动态和灵活的设置，并可以按需提供。

容器和 Kubernetes

云环境和基础设施即代码（IaC）的普及促使人们进一步思考如何打包软件应用程序，并将其传播到多个测试、预生产和生产环境中。

容器作为一种隔离进程及其资源的方法，已经有着悠久的历史，最早出现在 Unix 系统中，后来扩展到 Linux 系统。2013 年，Docker 成为第一家公司，不仅引入了自己的容器标准，还提供了一种管理容器的方式。Docker 提供的标准是如今描述、创建和管理容器时使用的最为普遍的标准。

什么是容器？如果我们从我们创建的应用程序开始，看看它在物理计算机服务器上如何分配资源，我们可以看到它的代码、库和数据占用了服务器的一部分内存，如下图所示：

图 1.2 – 物理服务器中的打包应用程序

虚拟机允许物理服务器托管多个虚拟机实例（虚拟机，VM）。每个虚拟机可以有自己独立的操作系统、应用程序和相关库。这些虚拟机由一个虚拟机监控程序（hypervisor）管理，虚拟机监控程序是运行在物理服务器上的一个应用程序进程。该安排如下所示：

图 1.3 – 物理服务器中的虚拟机和应用程序打包

Docker 或其他容器管理系统可以实现更高效的资源管理。容器只需要应用程序和任何依赖的第三方库的资源。任何所需的操作系统级资源都通过管理应用程序进行管理。在 Docker 的情况下，管理软件是 Docker 引擎。该安排如下所示：

图 1.4 – 容器与服务器打包

请注意，托管 Docker 引擎及其容器的服务器可以是物理服务器或虚拟机（VM）。这使得容器具备可移植性，唯一能在不同环境之间迁移的工件是容器的定义，即容器镜像。

借助容器的可移植性，开发人员可以创建应用程序并将其部署为可版本控制的工件，轻松转移到测试或生产环境中。开发中的应用程序可以被划分为服务。

Kubernetes 于 2015 年由 Google 提出，作为创建和管理由容器组成的集群的一种方式。这些集群允许从容器动态创建 Pods，从而构建灵活且具备弹性的服务或微服务。

现在我们已经了解了 DevOps 的基本原则以及推动其接受和普及的主要技术因素，是时候看看 Atlassian 的工具如何形成一个 DevOps 方法的工具链了。

从头开始创建一个 Open DevOps 工具链

使用 Atlassian 工具和 Open DevOps 的工具链的第一个链接是设置一个 Atlassian Cloud 组织。该组织中的第一个 Atlassian 产品将是 Jira。

在这个教程中，我们将探索如何创建一个组织并在安装 Jira 的 Atlassian Cloud 网站上进行操作。

如何操作...

让我们访问 Atlassian 网站，创建一个包含多个连接工具的 Open DevOps 环境：

1. Atlassian 的 Open DevOps 解决方案可以在 www.atlassian.com/solutions/devops 上查看。这个网站可以帮助您了解 Open DevOps 是什么，哪些第三方集成构成了解决方案的一部分，以及 Open DevOps 在 DevOps 最佳实践中的作用。

2. 在此页面，您可以通过选择页面上的 免费试用 按钮来请求创建一个带有 Jira 产品的新的 Atlassian Cloud 网站，如下图所示：

图 1.5 – Atlassian 的 Open DevOps 页面，带有“免费试用”按钮

1. 页面将打开，允许您连接一个现有的 Bitbucket 工作区，或者通过输入名称创建一个新的工作区。此面板如以下截图所示：

图 1.6 – 选择一个 Bitbucket 工作区

1. 创建一个新的 Bitbucket 工作区以连接到您的工具链。这是创建新工具链时的默认选项。如果您已有现成的 Bitbucket 工作区，也可以选择它。在做出选择后，点击 下一步。

2. 接下来的面板会提示您为新的 Atlassian Cloud 套件命名。.atlassian.net 前的文本必须是唯一的。此面板如下所示：

图 1.7 – 命名您的 Atlassian Cloud 套件面板

1. 为您的 Atlassian Cloud 网站命名并点击 下一步。

2. 新的面板应该会显示成功信息，提示您前往您的云站点上的 Jira 创建一个项目，如下图所示：

图 1.8 – Open DevOps 网站成功面板

1. 在整个过程中，面板已经明确表示无需信用卡，我们也不需要提供支付信息。我们在 Atlassian Cloud 网站上创建的内容是 Jira、Confluence 和 Bitbucket 的免费计划，以及 Opsgenie 的 DevOps 计划，后者对五个用户是免费的。

遵循这个教程可以创建一个完整的工具链，首先是 Jira、Bitbucket、Confluence 和 Opsgenie。

创建仅包含 Jira 的 Atlassian Cloud 网站

与创建一个包含多个产品的 Atlassian Cloud 站点相比，更模块化的方法是创建一个新的 Atlassian Cloud 站点并仅安装 Jira。其他 Atlassian 产品的安装可以根据需要进行。

为了做到这一点，我们将进入另一个着陆页面并按照提示操作，如以下步骤所示。

如何操作...

要在新的 Atlassian Cloud 站点上仅安装 Jira，请按照以下替代指示操作：

1. Atlassian 的 Jira 产品页面位于www.atlassian.com/software/jira。选择免费获取按钮，如下图所示：

图 1.9 – 从 Jira 产品页面选择免费计划

1. 在下一个面板上，如果你已登录 Atlassian 账户，它将显示该账户并提示你输入新的 Atlassian Cloud 站点名称。

图 1.10 – 创建新的 Atlassian Cloud 站点

1. 如前图所示，填写 Atlassian 账户和你希望的 Cloud 站点名称，然后点击同意。

按照这些指示，你将创建一个具有你指定名称的 Atlassian Cloud 站点，并授予管理员权限。接下来的部分将介绍如果你没有 Atlassian 账户，需要创建一个账户的场景。

还有更多...

如果你没有 Atlassian 账户或未登录 Atlassian 账户，你将被带到另一个页面以创建一个免费的 Atlassian 账户：

1. 你可以输入工作邮箱或使用常见的 OpenID 服务提供商账户，例如 Google、Microsoft、Apple 或 Slack。

2. 一旦账户创建完成，Atlassian 会提示你创建一个带有 Jira 免费计划的 Atlassian Cloud 站点，如前所示。

创建 Jira 项目

到目前为止，你已经创建了一个只包含 Jira 或 Jira 与 Confluence 的 Atlassian Cloud 站点，并连接了 Opsgenie 和 Bitbucket。

我们将通过设置使用工具链的 Jira 项目来开始我们的工具链创建过程。现在让我们看看如何进行。

如何操作...

在接下来的步骤中，你将创建一个 Jira 项目，该项目不仅记录开发团队的工作，还可以与其他工具的工件进行集成：

1. 前往你在本章前面步骤中创建的 Atlassian Cloud 站点。你可能会被提示通过选择项目模板来创建站点的第一个 Jira 项目，如下图所示：

图 1.11 – 选择项目模板

1. 选择一个与团队希望实践的敏捷方法论相匹配的项目模板（KANBAN或SCRUM），然后按下一步。

提示

通常，期望与利益相关者进行频繁反馈的团队会选择 Scrum，而希望监控并跟踪稳定工作流的团队则会选择 Kanban 项目。

1. 以下页面允许你选择其他选项，如名称以及项目是由公司管理还是由团队管理。公司管理的 Jira 项目将由 Jira 管理员设置项目元素，如自定义字段、工作流、通知和权限。团队管理的项目允许团队管理员进行所有自定义，但这些更改仅适用于该项目：

图 1.12 – 创建 Jira 项目详情

1. 如果你在 Atlassian Cloud 站点上创建了一个 Open DevOps 平台，它会自动创建其他文档，例如 Confluence 空间、Bitbucket 仓库和 Opsgenie 团队。下一个面板，如下图所示，展示了这一点：

图 1.13 – 创建的开放式 DevOps 文档

1. 如果你只在 Atlassian Cloud 站点上创建了 Jira，你将不会看到前面的界面（别担心；我们将在本章中的其他配方中展示如何连接其他工具）。相反，你将看到可以连接到 Jira 项目的其他工具，如下图所示：

图 1.14 – 连接其他工具

1. 你可以选择要连接的工具并按 下一步 以与其他工具集成，或者选择 跳过 以稍后进行集成。

通过遵循前面的步骤，你应该已经准备好了一个 Jira 项目，可以通过 Jira 中存储的问题或工作文档连接到必要的工具。

以下配方允许你在未选择 Open DevOps 平台来创建 Atlassian Cloud 站点，或者当 Jira 产品和项目已经创建时，进行连接。

连接 Confluence

Confluence 是 Atlassian 的第二古老工具。此前，它作为 Jira 的文档存储库，补充了在 Jira 中记录的开发活动的文档内容。

Confluence 通过将单独的页面组织成 空间 来工作。空间可以用于多种用途，如知识库或产品文档。

第一步是将 Confluence 添加到 Atlassian Cloud 站点。一旦添加完成，就可以为新的 Jira 项目创建一个新的空间。

准备就绪

不同的管理员为 Confluence 设置不同的内容。让我们简要了解一下 Atlassian Cloud 的不同管理层级。

组织管理员负责整个组织和其中包含的 Atlassian Cloud 站点的管理。他们为用户设置访问特定 Atlassian 产品的权限，并向 Atlassian Cloud 站点添加产品。

Confluence 管理员负责在 Confluence 实例中创建空间，并根据角色管理这些空间的用户权限。

我们将识别完成此操作步骤所需的管理级别。

如何操作...

我们将分两部分来处理这个操作步骤——第一部分是将 Confluence 添加到同时拥有 Jira 的 Atlassian Cloud 站点。第二部分是创建 Confluence 空间并将其与 Jira 项目连接。

将 Confluence 添加到 Atlassian Cloud 站点

让我们来看一下如何将 Confluence 添加到与 Jira 仅在创建新 Atlassian Cloud 站点并只使用 Jira配方中添加过的同一个 Atlassian Cloud 站点：

1. 作为组织管理员，请访问 start.atlassian.com 查找位于左上角的切换器图标。

图 1.15 – 在起始页面切换 Atlassian 应用程序

1. 点击前面图示中的图标，展示了应用程序选项。选择更多 Atlassian 产品，如后续图示所示：

图 1.16 – 选择 Atlassian 产品

1. 在打开的页面中，查找 Confluence 选项并点击立即试用。

图 1.17 – 尝试 Confluence

1. 输入要添加 Confluence 的站点名称并选择继续，如后续图示所示：

图 1.18 – 将 Confluence 添加到站点

执行这些操作后，应该会将 Confluence 产品添加到你的 Atlassian Cloud 站点中。

现在，让我们来看一下如何在 Confluence 中填充数据，具体表现为空间和页面。

创建 Confluence 空间并将其连接到 Jira 项目

让我们通过创建第一个空间来开始向 Confluence 添加数据：

1. 作为组织管理员或 Confluence 管理员，从菜单栏的首页选择中，点击SPACES部分中的+符号，如后续图示所示：

图 1.19 – 选择 + 创建空间

1. 在下一个页面上，选择一个空间模板或保持为空白模板。点击下一步。

图 1.20 – 选择 Confluence 模板

1. 给模板命名。你还可以指定空间的键。点击创建空间完成操作。

图 1.21 – 完成空间创建

1. 作为 Jira 项目管理员、Jira 管理员或组织管理员，导航至目标 Jira 项目。选择项目页面。然后，选择连接到 Confluence，或使用箭头图标查看你想连接的 Confluence 空间或页面。

图 1.22 – 连接 Confluence 空间

1. 选择已创建的空间并点击连接，如下图所示：

图 1.23 – 完成与空间的连接

你已经通过定义空间并将其链接到项目成功地将 Confluence 与 Jira 连接起来。更多关于这种集成所带来好处的应用，将在第三章的食谱中展示。

连接 Bitbucket

当前，Bitbucket 在 Atlassian Cloud 网站上与其他工具保持独立的位置，网址为bitbucket.org。在 Bitbucket 中，默认情况下，管理员和用户属于开发者组。

在 Bitbucket 方面，管理员组的成员必须创建仓库或 repo。这个仓库可能会在 Bitbucket 项目中与其他仓库分组。Bitbucket 的最上层是工作区，这可能类似于组织的顶层。

在 Jira 方面，我们需要一个 Jira 项目管理员来将仓库连接到 Jira 项目。

让我们来看一下涉及的步骤。

如何操作...

让我们来看一下连接 Bitbucket 所涉及的步骤。

在 Bitbucket 中创建仓库

执行以下步骤以在 Bitbucket 中创建仓库：

1. 作为 Bitbucket 管理员，选择仓库菜单栏并点击创建 仓库按钮。

图 1.24 – 创建 Bitbucket 仓库

1. 在接下来的页面中，填写仓库名称并选择该仓库所属的项目（这些是唯一的必填项），以及其他所需的详细信息。完成后点击创建仓库按钮。

图 1.25 – 完成仓库创建

现在我们已经拥有一个 Bitbucket 仓库，让我们将其连接到一个 Jira 项目。

将仓库连接到 Jira 项目

按照以下步骤，将 Bitbucket 仓库中的数据集成到 Jira 项目中：

1. 作为 Jira 管理员，在 Jira 项目中，从左侧选项中选择项目设置。

图 1.26 – 选择项目设置

1. 选择开发工具，如下图所示：

图 1.27 – 选择开发工具

1. 默认情况下，Bitbucket 在开发工具页面上显示为已连接至 Jira。我们可以通过选择连接下拉菜单并从选项中选择Bitbucket Cloud来调整连接设置。

图 1.28 – 连接 Bitbucket Cloud

1. 在Jira 请求访问页面，授权 Jira 访问你创建仓库的 Bitbucket 工作区，通过选择工作区并点击授予访问权限。

图 1.29 – 授予 Bitbucket 工作区访问 Jira 的权限

1. 在DVCS 账户页面，选择允许智能提交的仓库，然后点击链接 Bitbucket Cloud 工作区按钮。

图 1.30 – 添加仓库并链接 Bitbucket Cloud 工作区

通过将 Bitbucket 仓库连接到 Jira 项目，就像按照之前的说明所做的那样，你将工作的原因（为什么做）与工作的实施（怎么做）相连接。

第二章：通过 Jira 产品发现了解客户需求

我们从探索 DevOps 生命周期开始，看一看价值流的典型触发器，这是 DevOps 思维的重要构成。这个触发器通常是一个想法或新思想，可以表达为一个新产品或功能。Jira 产品发现（JPD），是 Atlassian Jira 家族中的一款产品，允许用户创建和跟踪称为想法的工作项，以记录构思过程。在决定继续实施之后，可以将其作为 Jira 中的史诗进行开发。

在本章中，我们将探讨使用 JPD 存储、详细说明和优先考虑想法。想法的使用和维护可以更好地组织，轻松确定哪些想法应该进入实施阶段。因为 JPD 像本书中提到的其他 Atlassian 工具一样，都基于 Atlassian 云，所以我们将讨论限于 Atlassian 云的安装和配置。因此，本章的食谱包括以下内容：

• 采用 JPD

• 创建 JPD 项目

• 查看想法

• 创建想法

• 在字段、评论、附件和见解中添加补充信息

• 在 Jira 中为开发提供想法

现在让我们开始在我们的 Atlassian 云站点上安装 JPD。

采用 JPD

JPD 可以使用以下两种许可计划之一进行安装：

• 为最多三名授权用户（称为创建者）提供免费计划

• 针对更大团队的付费标准计划，即有超过三名创建者的团队

本篇将重点介绍如何安装免费计划。组织管理员可以根据需要从免费计划切换到标准计划，反之亦然。

准备工作

如我们在第一章中看到的，Atlassian 云上有不同级别的管理。一些功能只能由组织管理员执行，而其他功能可能由组织管理员和产品管理员（在本例中是 Jira 管理员）共享。

本篇食谱仅由组织管理员执行。

如何执行...

按照介绍中讨论的内容，按照以下说明在您的 Atlassian 云站点上安装 JPD：

1. 作为组织管理员，请转到任何 Atlassian 云产品页面左上角的网格图标，以切换您希望在其上安装 JPD 的站点。如果您负责多个 Atlassian 云站点，请找到您想管理的站点。

2. 推荐给您的团队部分的具有 JPD 条目的站点未安装 JPD。这可以在以下插图中看到：

图 2.1 – 选择 Jira 产品发现

1. 选择 JPD 的任一入口都将带您进入Jira 产品发现产品页面，介绍 JPD 的功能和好处。选择立即试用按钮。

图 2.2 – 选择参与 JPD

1. 然后，Atlassian 会将免费计划添加到您的组织的 Atlassian 云站点。当完成时，您将看到以下消息：

图 2.3 – JPD 成功消息

在添加产品后，组织管理员将被提示创建 JPD 项目。此外，Jira 管理员可能需要创建一个新的 JPD 项目，以存储新的产品创意。让我们在下一个步骤中查看这两种用例。

创建 JPD 项目

与其他 Jira 产品（如 Jira 和 Jira 服务管理）一样，JPD 使用项目的概念来存储工作并管理执行工作的人员。

JPD 项目将以创意的形式存储工作，这些创意是新产品或产品功能的潜在起点。参与创意工作的人可以是创作者、拥有许可的用户（负责创建创意），或是非授权贡献者（作为利益相关者添加补充数据和情感），他们可以决定该创意是否适合开发。

如何操作...

创建 JPD 项目的其中一种情况是由组织管理员添加 JPD 产品时发生的。让我们接着之前步骤中的内容继续。

添加 JPD 项目到产品后

在成功安装 Jira 产品发现 (JPD) 后，它会提示您创建初始项目。让我们查看创建项目的步骤：

1. 一旦 JPD 成功安装到 Atlassian 云站点上，组织管理员可以点击初始Jira 产品发现页面上的开始使用按钮，接着会看到一个窗口，提示他们通过添加项目名称和关键字来创建第一个项目。

图 2.4 – 创建您的第一个项目窗口

1. 在输入所需的名称和关键字并点击创建项目后，JPD 项目将成功创建。项目名称和关键字必须唯一。如果名称或关键字与现有项目相同，Jira 会显示错误并不允许创建项目。

创建新 JPD 项目

Jira 管理员可以通过与 Jira 和 Jira 服务管理相同的用户界面创建 JPD 项目。要通过 Jira 界面创建新的 JPD 项目，请执行以下步骤：

1. 从菜单栏的项目下拉菜单中，选择创建项目，如下图所示：

图 2.5 – 选择创建项目

1. 在项目模板页面上选择项目模板。JPD 项目模板位于产品 管理类别中。

图 2.6 – 选择项目模板

1. 在下一个页面上，选择使用模板。这将设置项目，确保项目具有 JPD 所使用的正确问题类型和视图。

图 2.7 – 选择使用模板

1. 在添加项目详情页面中，添加项目详细信息。为您的项目命名并指定项目密钥。选择访问级别后，点击创建项目，如图所示。

图 2.8 – 创建项目

1. 选择的访问级别对谁被视为创建者并因此计费有影响。访问级别分为三种，具体定义如下：

   • 私密：只有项目管理员指定的用户才能访问该项目。项目管理员还可以决定谁是创建者，谁是贡献者。

   • 有限：所有人都可以访问该项目。项目管理员可以决定谁可以作为创建者。

   • 公开：所有人都可以访问该项目。任何具有产品访问权限的人都会被赋予创建者角色。

2. 一旦项目成功创建，任何成员都可以看到项目的默认想法视图。此视图可能类似于以下截图：

图 2.9 – JPD 项目视图

从这里，我们可以开始查看下一个方案：深入了解如何查看想法。

查看想法

想法是存储在 JPD 项目中的关键项。想法通过视图进行显示和组织。

视图提供了几个重要功能。它们可以根据完成时间、执行团队等标准来组织和排序项目中的想法，也可以根据影响力对竞争性想法进行比较。

视图基于以下四种视图类型，可以以不同的方式组织想法：

• 列表：以表格格式显示想法，并包含相关字段。默认示例包括影响评估和交付状态。

• 看板：这显示了一个看板，列代表不同的状态或处理方式。一个默认示例是产品路线图。

• 矩阵：用于基于两个标准比较想法。一个例子是影响力与努力的对比。

• 时间轴：按开发和发布的时间顺序显示想法。默认示例是产品时间轴。

让我们更详细地看看如何与视图进行交互。

如何操作...

视图具有以下功能：

• 评论

• 分组想法

• 筛选想法

• 排序想法

• 编辑想法字段

• 创建想法

在视图内创建和编辑想法的直接操作将在下一节中讨论。现在，让我们来看看如何在视图中组织我们的想法。

添加评论

任何拥有 JPD 项目访问权限的人员，无论是创建者还是贡献者，都可以在任何视图上发表评论。

让我们来看一下从视图中添加对我们想法的评论：

1. 要在视图中创建评论，请选择评论按钮，如下图所示：

图 2.10 – 视图的评论按钮

1. 一个窗口会在评论按钮下方打开，如下图所示。点击文本框开始创建评论。

图 2.11 – 开始创建评论

1. 文本框将展开，显示评论样式和内容的控制选项。添加评论后，点击创建完成评论创建。

图 2.12 – 评论创建框

1. 一旦创建了评论，评论按钮将显示该视图下的评论数量。现有的评论将出现在创建评论文本框下方。

图 2.13 – 现有评论和评论数量

分组思想

你可以根据共同标准对思想进行分组，比如客户细分、创作者、目标或其他有助于确定哪些思想应优先的特质。在列表、看板和时间线视图中都可以进行思想分组。按照以下步骤在视图中对思想进行分组：

1. 要在视图中分组思想，点击视图中的按分组按钮，如此处所示。

图 2.14 – 创建分组

1. 选择分组选项的标准会从右侧打开，如下所示。请选择要用于分组思想的领域，从下拉菜单中选择。

图 2.15 – 分组选择菜单

1. 选定后，视图将发生变化，思想将按组分类，可以展开查看其中的思想。分类将把问题划分到视图中的泳道内，如下图所示：

图 2.16 – 按组查看

过滤思想

所有视图类型都可以过滤，以便使符合过滤标准的思想出现在视图中。这可以用来集中关注特定思想，帮助优先排序。按照以下步骤设置过滤器：

1. 要设置过滤器，点击过滤器按钮。

图 2.17 – 创建视图过滤器

1. 会从右侧打开一个过滤器区域。选择添加过滤器以创建过滤器。

2. 如图所示，会出现一个下拉菜单，列出思想领域。选择字段并选择所需的字段选项作为过滤标准。

图 2.18 – 选择视图的过滤标准

1. 完成过滤器选择后，点击右上角的X按钮。

通过遵循上述步骤，你可以选择通过过滤器查看视图中显示的思想。只有符合过滤标准的思想会出现在视图中，如下图所示：

图 2.19 – 应用过滤器的视图

让我们来看一下在视图中组织想法的另一种方式。有时，想法需要按照特定顺序排列。排序有助于确定这个顺序。

排序想法

你可以通过设置排序顺序来确定想法在视图中出现的顺序。建立排序顺序有助于组织和优先排序想法，并且可能有助于确定哪个想法应该进入实施阶段。此功能仅适用于列表、看板和时间线视图类型。执行以下步骤来排序你的想法：

1. 要进行排序，请按排序按钮。

图 2.20 – 按下排序

1. 排序窗口将从右侧打开。选择用于主要和次要排序的想法字段，必要时可以选择第三排序。

图 2.21 – 设置排序顺序

1. 完成排序选择后，点击右上角的X按钮。

   如果查看你的视图，你应该会看到你的想法已经根据你设置的标准进行了排序。下图显示了按升序影响得分排序的效果，这会逆转默认的排序顺序：

图 2.22 – 设置了排序顺序的视图

现在，我们已经准备好查看 JPD 中的想法。让我们来看看创建 想法部分。

创建想法

想法是 JPD 中的主要成果。想法允许为新产品和功能提供描述和理由。通过在想法中使用以下功能，想法成为所有补充信息的存储库：

• 字段

• 评论

• 附件

• 见解

让我们来看看通过填写前述功能来创建想法，既可以单独操作，也可以在视图的上下文中进行。

准备就绪

默认情况下，只有拥有创建者角色的用户才能在 JPD 项目中实际创建想法。

Jira 管理员可以通过在侧边栏选择项目设置选项，允许拥有贡献者权限的用户在项目中创建想法。

图 2.23 – 选择项目设置

从项目设置侧边栏选项中，展开功能并选择创建想法。页面应与以下截图相似：

图 2.24 – 创建想法设置

开启允许贡献者创建想法的切换按钮，以便启用该功能。

请注意，启用后，贡献者可以创建想法，但无法编辑或删除它们。对于任何想法，贡献者可以添加评论、附件和见解。

如何操作...

在 JPD 项目中，有多种创建新想法的方式。典型的创建位置包括以下几种：

• 导航栏上的蓝色创建按钮

• 在任何视图中，都可以通过创建想法按钮或添加 想法控件来创建想法。

让我们看看如何使用这些模式创建想法。

从“创建”按钮创建一个想法

执行以下操作以使用创建按钮创建一个想法：

1. 一旦你确定了谁可以创建想法，他们可以点击导航栏上的蓝色创建按钮。

图 2.25 – 使用创建按钮

1. 会出现一个窗口，包含创建想法所需的标准字段。填写这些字段并点击创建按钮。

图 2.26 – 创建想法窗口

1. Jira 管理员可以通过创建表单来更改窗口中显示的字段。这也可能包括通过使用模板预填充描述字段。

按照之前的指示创建的想法可以在任何 JPD 项目的视图中看到。以下截图展示了一个创建的想法示例。

图 2.27 – 显示新创建的想法

从列表视图中创建想法

JPD 的列表视图以表格格式显示想法。常见字段如摘要、目标、影响评分和工作量显示为表格中的列。

默认视图，如所有视图、影响评估和交付状态，都设置为列表视图。这些列表视图可以从侧边栏的视图部分中访问。此外，你还可以创建自定义的列表视图。

让我们来看看在列表视图中如何创建一个新想法：

1. 在视图可见的情况下，选择创建想法按钮，如下图所示：

图 2.28 – 创建想法按钮

1. 顶部会打开一行，允许你输入新想法的摘要。键入摘要后按Enter键。

图 2.29 – 输入新想法的摘要

新创建的想法现在应该可以在你的列表视图中看到。

图 2.30 – 列表视图中的新想法

现在让我们进一步了解路线图视图以及如何在该视图中创建新想法。

在路线图视图中创建想法

路线图视图按照想法的实施时间来显示想法。在路线图视图中，代表现在、下一个和稍后时间点的列中包含代表想法的卡片。这使得能够可视化哪些想法应该尽早完成，而不是拖延。

可以通过在侧边栏的视图部分中选择来访问路线图视图。

让我们来看看当我们处于产品 路线图视图时如何创建一个新想法：

1. 在路线图中，选择你希望想法出现的列，并点击列底部的+ 添加想法按钮。

图 2.31 – 向路线图视图中添加想法

1. 在出现的搜索区域中，输入新想法的摘要。

图 2.32– 输入新想法的摘要

现在我们有了一个在路线图中的新想法。

图 2.33 – 路线图视图中的新想法

在矩阵或时间线视图中创建想法

矩阵视图和时间线视图在二维空间中展示想法，想法的位置代表其在矩阵视图中的重要性，比如影响与努力的对比，或者它在时间线视图中预定的实施时间。

与其他视图一样，矩阵和时间线视图可以从侧边栏的视图部分访问。

在矩阵视图或产品时间线视图中创建新想法时，请执行以下步骤：

1. 在矩阵视图或产品时间线视图中，右下角会出现一个带加号的蓝色圆圈。选择该蓝色圆圈以创建新想法。

图 2.34 – 在产品时间线视图中创建一个想法

1. 圆圈会扩展，显示可以添加到视图中的想法。在这些想法下面，有一个创建新 想法按钮。

图 2.35 – 创建新想法

1. 按钮变为文本框，如下图所示，允许你输入新想法的摘要。按下Enter键完成创建。

图 2.36 – 添加新想法

然后，可以通过从添加想法区域将新想法拖放到产品时间线或矩阵视图中，放置在需要的位置。

图 2.37 – 将新想法拖放到时间线视图

一旦创建了一个想法，我们可能希望添加补充信息以记录学习过程，并帮助决策。接下来的操作将演示如何向想法中添加额外信息。

向想法中添加信息

一旦创建了想法，创作者和协作者可以为其添加上下文，以展示想法的发展，并帮助促进决策。添加这些信息的常见方法包括使用以下方式：

• 字段

• 评论

• 附件

• 洞察

让我们来看看添加这些信息的常见方法。

准备就绪

权限可以决定谁有权限添加信息。字段只能由创作者修改。创作者和协作者都可以添加评论、附件和洞察。

如何操作...

可以从以下位置添加字段、评论、附件和洞察：

• 在选择某个想法时出现的页面上

• 从点击视图中某个想法时出现的扩展右侧面板

• 直接在视图中（对于列表视图类型）

让我们看看如何添加这些信息。

在思路页面添加

让我们看看如何在思路的页面上添加数据：

1. 思路通常可以通过点击项目中任何位置的思路 ID 来显示在自己的页面上，但最常见的方式是从视图中显示。思路页面显示了字段、评论、附件和见解的位置标签。

图 2.38 – 思路页面

1. 评论和见解设置为标签页字段。选择评论查看所有评论并输入新评论。在文本区域中输入新评论并点击创建按钮完成。

图 2.39 – 输入评论

评论与该思路的其他评论一起显示。

图 2.40 – 带有现有评论的新评论

1. 选择见解查看链接到其他来源，或者通过点击创建见解按钮自己创建这样的链接。输入见解来源的链接，并在文本区域中输入描述性文本。完成后点击创建按钮。

图 2.41 – 输入见解

新的见解将出现在见解列表的顶部。

图 2.42 – 带有其他见解的新见解

我们已经看到可以在思路的页面上添加相关信息。让我们来看看如何在选择视图中的单个思路时打开的思路面板中做同样的事情。

从思路面板添加

你可以在视图中点击任何思路，允许思路面板显示在视图的右侧。这里展示了思路面板。

图 2.43 – 思路面板

评论和见解可以通过各自的按钮查看和添加。附件可以通过添加附件按钮添加。可以通过滚动到字段、点击该字段并选择所需的值来修改字段。

之前的步骤已允许我们通过思路面板向思路添加相关信息。

从列表视图修改

列表视图以表格的形式布局，如截图所示。行表示思路，列表示字段。

图 2.44 – 列表视图和字段

创作者可以通过进入代表思路的行和代表字段的列的交点来修改思路的字段。点击单元格可以修改字段。一些功能，如评论和见解，可以设置为额外的列。

一旦思路被批准实施，我们需要将其与实施进行关联。下一个流程将通过在 Jira 中创建一个关联的史诗来实现这一点。

在 Jira 中提交开发思路

当想法准备好进行开发时，可以将其与 Jira 中的史诗关联。随着史诗的创建，原始想法和生成的史诗之间将建立链接。还可以通过查看关联的 Jira 问题的状态来确定交付进度。

让我们来看看如何将 JPD 与 Jira 链接。

准备就绪

在创建史诗之前，请验证以下内容：

• 至少有一个 Jira 项目可用于容纳史诗。

• 创建史诗的人具有在目标项目中创建史诗的适当权限。这个人应当是 JPD 项目的成员或 Jira 管理员。

当满足这两个条件时，就可以轻松地在 JPD 中创建作为交付票据的史诗。

如何操作...

从以下两个位置可以创建作为交付票据的史诗：

• 在想法页面上

• 在视图中的想法面板

让我们来看一下如何从这些位置创建史诗。

从想法页面创建史诗

要在 Jira 中创建与 JPD 中的想法关联的史诗，请执行以下步骤：

1. 在想法页面上，点击交付标签。

图 2.45 – 在想法页面上选择交付标签

1. 交付标签将展开，提供以下两个选项：

   • 创建一个新的交付票据（史诗）

   • 创建与现有交付票据的链接

2. 选择创建交付票据将显示项目、问题类型和摘要的文本框，如下所示。

图 2.46 – 创建交付票据

1. 选择项目和问题类型，并在点击创建之前填写所需的摘要。

现在，史诗已出现在 Jira 项目中，并且与您的想法关联。

从想法面板创建史诗

让我们来看看如何从想法面板创建一个史诗并将其与我们的想法关联起来：

1. 从视图中选择一个想法，以在右侧显示想法面板。你应该会看到面板顶部附近的交付标签，如下图所示：

图 2.47 – 想法面板中的交付标签

1. 交付标签将展开，提供以下两个选项：

   • 创建一个新的交付票据（史诗）

   • 创建与现有交付票据的链接

2. 这些内容在下图中进行了说明。

图 2.48 – 创建交付票据

1. 选择创建交付票据将显示项目、问题类型和摘要的文本框，如下所示。

图 2.49 – 填充交付票据信息

史诗将出现在交付票据的列表中。

图 2.50 – 交付票据的显示

在本章中，我们探讨了 JPD 的功能，它能够帮助我们跟踪和优先排序产品想法，并决定何时将其发送给开发团队进行实现。这项新工作启动了开发和运维团队用于开发、发布和维护产品的 DevOps 循环。

第三章：使用 Confluence 进行规划和文档编写

在我们开始开发过程时，我们必须寻找一个方便的地方来记录我们的进展，明确工作范围，并说明我们将如何进行开发过程。对于许多组织来说，这个地方是Confluence。

将 Confluence 与 DevOps 工具链中的其他产品集成，可以让你将来自这些工具的工件链接到 Confluence 文档页面。这些页面的内容可能包括计划和其他项目数据，以及来自 Bitbucket 的代码内容。通过允许 Confluence 页面与 Jira 和 Bitbucket 中的工件之间的紧密集成，作为 Confluence 页面创建的文档工件拥有了更丰富的上下文，从而增强了其意义并提高了理解。

本章中，我们将利用 Confluence 与其他可用的 Atlassian DevOps 工具链工具之间的集成。为此，我们将介绍以下配方：

• 创建与 Jira 项目链接的 Confluence 页面

• 在 Confluence 页面中显示 Jira 问题

• 在 Confluence 页面中查看 Jira 生成的报告

• 在 Confluence 页面中查看 Jira 路线图

• 使用智能链接查看其他应用程序中的链接页面

技术要求

为了完成本章中的配方，你需要创建一个安装了 Jira 和 Confluence 的 Atlassian Cloud 网站。连接 Confluence 和 Jira 的方法在第一章的《连接 Confluence》配方中已有讲解。

此外，Jira 管理员以及可能的 Jira 项目管理员必须确认你已启用浏览项目权限，且该权限适用于你要工作的项目。Confluence 空间管理员必须确认你在正确的组中，并且已启用页面、白板和智能链接，如以下截图所示：

图 3.1 – 添加页面、白板和智能链接的空间权限

现在我们已经涵盖了前提条件，接下来让我们从将 Confluence 链接到 Jira 项目开始。

创建与 Jira 项目链接的 Confluence 页面

我们在第一章中学习了如何集成 Jira 和 Confluence。在每个 Jira 项目中，成员可以直接从 Jira 创建和修改 Confluence 内容。

Confluence 页面与 Jira 项目之间的集成使你能够将文档与项目产生的事件和工件紧密联系。以下是一些文档示例：

• 用户文档

• 需求规范

• 会议记录

• 发布说明

让我们学习如何创建这样的内容并将其连接到 Jira 项目。

如何操作……

你可以在不离开 Jira 的情况下创建 Confluence 页面。这提高了工作效率，因为它消除了不必要的上下文切换。

让我们看看怎么做：

1. 从你的 Jira 项目中，选择左侧边栏中的项目页面，如下面的截图所示：

图 3.2 – 选择项目页面

1. 页面将显示来自 Confluence 的任何内容，例如已经连接的页面或空间（页面的集合）。从这里，你有以下选项：

   • 编辑当前已连接的页面

   • 在顶层创建新页面

   • 为现有页面创建一个新的子页面

让我们更深入地了解这些选项。

编辑现有页面

请按照以下步骤操作：

1. 在项目页面页面，找到你想编辑的页面。将鼠标悬停在与该页面对应的行上，你应该会看到一个铅笔图标，如下所示：

图 3.3 – 选择要编辑的页面

1. 选择铅笔图标会打开一个模态窗口，页面准备进行编辑。进行更改后，点击更新以发布更改的页面。

   在这里，你从 Jira 进入了 Confluence，并通过 Confluence 编辑页面。该行会更新，指示它已被最近编辑。

图 3.4 – 在 Jira 中更新的页面

创建新页面

请按照以下步骤操作：

1. 在项目页面页面的右侧，有一个显示相关页面模板的部分。

图 3.5 – 为新页面选择模板

1. 选择模板将打开一个新页面，模板将以模态的形式使用，如下所示：

图 3.6 – 编辑新页面

1. 进行所需的更改，点击发布将页面发布到 Confluence 或 Jira 中，使其他人可以查看。该页面将出现在空间的顶层。

   现在，你应该已经在 Confluence 中创建了一个全新的页面，并且该页面与 Jira 项目连接。

图 3.7 – 在 Jira 中看到的新页面

创建子页面

请按照以下步骤操作：

1. 在项目页面页面，找到你想用作父页面的页面。将鼠标悬停在代表该页面的行上，查看各种工具，例如铅笔图标。选择加号（+）。

图 3.8 – 选择父页面

1. 一个你想编辑的页面将作为模态窗口打开。进行所需的更改后，点击公开，使页面在 Confluence 或 Jira 中可供其他人查看。

到目前为止，我们添加到 Confluence 页面上的内容都是我们使用默认文本编辑器编辑的文本。在接下来的操作中，我们将看看如何向这些页面添加特殊内容。

在 Confluence 页面上显示 Jira 问题

将 Confluence 与 Jira 集成可以向 Confluence 页面添加增强的内容，以便用于文档目的。通过集成添加的内容会实时更新，使 Confluence 页面变得动态。

你可以通过使用 宏 将 Jira 问题集成到 Confluence 页面中。这些是 Confluence 本地支持的附加功能，或可以通过 Atlassian Marketplace 应用添加。它们提供了增强的格式化功能，并允许你添加内容。

让我们仔细看看如何使用 Confluence 宏。

如何操作……

我们将使用宏执行以下操作：

• 显示来自 Jira 项目的现有 Jira 问题

• 创建新的 Jira 问题

每个操作都使用不同的宏。

显示现有的 Jira 问题

让我们看看显示现有 Jira 问题的宏：

1. 要查看可用的宏，请选择你正在编辑的页面上的加号 (+) 或编辑 Jira 中的模态框，如下所示：

图 3.9 – 添加宏

1. 搜索适当的 Jira 专用宏。在这种情况下，我们要从下拉菜单中找到 Jira 问题 宏，如下图所示。你可以按关键词搜索或选择一个类别。选择 查看更多 以查看所有类别。

图 3.10 – 搜索宏

1. 当选择 查看更多 时，可以通过类别或搜索它们来访问所有可用的宏。在页面上选择你希望使用的宏并点击 插入。

图 3.11 – 从浏览屏幕选择宏

1. 在我们的例子中，我们要查找 jira 并从出现的选项中选择它。

图 3.12 – 选择 Jira 问题宏

1. Jira 问题 宏通过 BASIC 搜索机制或更高级的 Jira 查询语言 (JQL) 查询来查找要显示的问题。搜索所需的问题并选择 插入问题。

图 3.13 – 选择 Jira 问题

现在我们知道如何使用宏来添加内容，让我们看看如何使用宏来创建新的 Jira 问题。

创建新的 Jira 问题

要创建一个新的 Jira 问题并将其链接到我们的 Confluence 页面，我们将使用一个不同的宏。按照以下步骤通过宏创建新的 Jira 问题：

1. 我们可以在 开发 类别中查找 Jira 宏，如下图所示。选择 创建 Jira 问题 宏并点击 插入。

图 3.14 – 选择创建 Jira 问题宏

1. 你可以用来编辑新 Jira 问题的字段将以模态框的形式显示。填写所需的字段，然后点击 创建 以记录新的 Jira 问题。

图 3.15 – 创建 Jira 问题

一旦创建，Jira 问题可以被格式化，以便在 Confluence 页面上显示。你可以选择以下配置之一：

• URL

• 一行文本

• 作为一个卡片，显示几个字段

• 嵌入到页面中

如果 Confluence 页面处于编辑模式，可以更改所需的格式。

这样，你应该在 Confluence 页面上看到一个新的 Jira 问题。

另见

关于使用 JQL 创建查询的更多信息，请查看以下资源：

• www.youtube.com/watch?v=KC7vPPP2sQo

• www.youtube.com/watch?v=Bbvl9PqCePA

• www.atlassian.com/software/jira/guides/jql/overview#what-is-jql

在 Confluence 页面上查看 Jira 报告

在 Jira 上创建的相同报告可以在 Confluence 页面上复制并显示。宏允许你复制和显示这些报告。这些宏是 Confluence 内置的，或者可以由第三方 Atlassian Marketplace 应用程序提供，如 Jira 的自定义图表。

你可能会想，“如果报告已经在 Jira 中，为什么还要使用 Confluence？”答案是，Confluence 提供了在项目更大背景下查看报告的视角。报告可以嵌入到 Confluence 页面中，或作为 Confluence 空间的一部分，这样所有项目信息就集中在一个地方，便于查阅。

让我们来看看如何在项目的 Confluence 页面上启用这些报告宏。

如何操作…

以下宏可以用于 Confluence 中的报告：

• JIRA 报告模板：这是一个 Confluence 页面模板，用于基于文本的报告，例如变更日志或状态报告。

• JIRA 图表宏：此宏允许你插入自定义的二维图表、创建与解决的图表或饼图。

让我们学习如何使用这些宏在 Confluence 中创建关于 Jira 数据的报告。

使用 JIRA 图表宏

我们首先来看看 JIRA 图表宏：

1. 当你浏览宏时，开发类别下可以找到报告宏，如下所示：

图 3.16 – 浏览开发类别以查找报告宏

1. 选择JIRA 图表并点击插入。

2. 另一种查找和选择任何 Confluence 宏的方法是，在编辑 Confluence 页面时进行。只需在空行中添加反斜杠字符（/），如图所示：

图 3.17 – 在编辑 Confluence 页面时选择宏

1. 继续输入宏的名称（在此为JIRA 图表）。内置的搜索功能将在你输入时限制可能的选项。当你找到所需的宏时，选择它。

2. 从浏览模态窗口或通过内联编辑选择后，报告宏的各种配置选项将出现在模态窗口中。配置所需的选项，包括数据源、刷新间隔和格式。以下是一个示例：

图 3.18 – 配置 JIRA 图表宏

1. 如我们所见，配置内容包括选择图表类型（二维图、已创建与已解决或饼图）、通过 JQL 查询或筛选器指定数据源，以及各种显示选项，包括对数据进行分组。配置完成后，点击插入。以下截图展示了使用已创建与已解决图表进行此类配置的示例：

图 3.19 – 设置 JIRA 图表宏的配置

1. 图表将生成并添加到 Confluence 页面。生成的页面应类似于以下内容：

图 3.20 – Confluence 页面上的 Jira 图表

按照之前的步骤，你已经创建并配置了 Jira 图表，并将其显示设置为 Confluence 页面。

其他报告使用JIRA 报告模板。

使用 JIRA 报告模板

让我们来看一个创建 Confluence 页面并配置报告的示例。像变更日志或状态报告这样的报告可以成为设计文档的基础，并在整个项目中进行更新。请按照以下步骤操作：

1. 使用JIRA 报告模板创建一个新的 Confluence 页面。你可以通过在创建页面部分使用更多模板选项来搜索此模板。

图 3.21 – 使用“更多模板”选项

1. 在打开的页面中，搜索框输入 Jira report。你应该看到以下结果：

图 3.22 – 查找 JIRA 报告模板

1. 选择JIRA 报告模板并点击使用，将打开一个模态窗口，在其中你可以选择报告类型，如下所示：

图 3.23 – 选择报告类型

1. 选择你希望使用的报告类型并点击下一步，将打开另一个页面，你可以在其中选择你要创建状态报告的项目并编辑其标题。

图 3.24 – 创建状态报告

1. 在前面的图中，我们选择了状态报告并确定了它的项目。点击创建按钮后，相关页面将被创建。

通过这个方法，我们已经基于JIRA 报告模板创建了一个可在 Confluence 页面上显示的 Jira 变更日志或状态报告。

图 3.25 – 我们新创建的变更日志

在 Confluence 页面上查看 Jira 路线图

如果您在项目中创建了时间线，您可以将该时间线作为路线图显示在 Confluence 页面上。我们将使用Jira 时间线宏来实现这一点。

如何操作…

让我们学习如何在 Confluence 页面上创建 Jira 路线图：

1. 在 Confluence 页面上，找到 Jira 时间线宏。找到后，添加它。

图 3.26 – 配置 Jira 时间线宏

1. 前往项目的Jira 时间线页面，将 URL 复制并粘贴到粘贴 Jira 实例 URL文本区域，然后点击保存。

通过粘贴Jira 时间线页面的 URL，您已将 Jira 路线图链接到 Confluence 页面。

到目前为止，我们已经讨论了如何将 Jira 连接到 Confluence，使 Confluence 能够显示 Jira 相关内容。在下一个操作中，我们将关注连接其他应用程序，使它们也能做到这一点。

使用智能链接查看来自其他应用程序的链接页面

存在于其他应用程序中的内容，如 Bitbucket、GitLab 和 Figma，可以通过智能链接在 Confluence 页面上动态显示。智能链接允许 Confluence 显示来自各种应用程序的 URL 链接，包括 Atlassian 产品如 Bitbucket 和 Jira，可以内嵌或以行内方式展示。

让我们仔细看看如何使用智能链接将链接页面内容嵌入到 Confluence 页面中。

准备工作

智能链接可以从 Atlassian 和非 Atlassian 产品中创建。以下 Atlassian 产品可以将其链接指定为智能链接：

• Atlas

• Atlassian 分析

• Bitbucket

• Compass

• Jira

• Jira 路线图

• Jira Align

• Trello

常用于应用程序开发过程中的非 Atlassian 产品，以及在 Confluence 中作为智能链接显示的链接包括 Azure DevOps、GitHub 和 GitLab。支持的应用程序完整列表可以在 support.atlassian.com/confluence-cloud/docs/insert-links-and-anchors/#Smart-Links-from-Jira-and-other-products 查找。

让我们仔细看看设置智能链接涉及的内容。

使用其他应用进行身份验证

对于任何需要身份验证的非 Atlassian 产品，您必须先登录该应用程序，才能在 Confluence 页面上显示智能链接。您只需登录一次。这将在该 Atlassian Cloud 组织的所有站点上生效。

如何操作…

通过身份验证后，让我们创建并配置我们的智能链接：

1. 在编辑模式下的 Confluence 页面中，复制第二个应用程序中所需的 URL 并粘贴到 Confluence 页面上的所需位置。

2. 要调整链接内容的格式，请点击智能链接。各种控制项将出现，如下截图所示：

图 3.27 – 智能链接控制

1. 前四个图标决定了链接的显示方式。从左到右的顺序如下：

   1. 原始 URL

   2. 链接页面的标题

   3. 卡片模式显示链接页面的标题和描述（如前面的截图所示）

   4. 嵌入模式，其中链接页面的内容将可见

   其他控制项允许您执行以下操作：

   1. 编辑基础 URL 链接

   2. 在另一个浏览器标签页中打开链接的页面

   3. 复制 URL 链接

   4. 打开链接 偏好设置页面

   5. 从 Confluence 页面中移除智能链接

让我们仔细看看链接偏好设置。

使用链接偏好设置

链接偏好设置是按账户设置的——即，它们是单个用户创建的所有智能链接的首选设置。因此，它们会显示在用户的 Atlassian 账户设置中，可以在 id.atlassian.com 下找到。让我们仔细看一下：

1. 在上述页面中，您将找到以下设置：

   • 默认显示：设置创建智能链接时的默认显示方式

   • 特定域名的例外：根据链接的域名指定例外

图 3.28 – 链接偏好设置页面

1. 要设置默认显示方式，请选择所需的模式（显示 URL、显示内联或显示卡片）。

2. 要为默认显示设置例外，请输入域名的 URL，选择所需的模式（显示 URL、显示内联、显示卡片或显示嵌入），然后点击提交。

这样，我们就设置了 Atlassian 在创建个人智能链接时所使用的配置，以及如何创建智能链接。

第二部分：从开发到部署

在开发过程的这一部分，我们正在开发我们的实现。这要求开发的软件处于版本控制之下，我们会追踪所有相对于之前版本的更改。

在 Git 提交执行后，管道立即启动。进行扫描和测试以查找错误和安全漏洞。如果一切通过，管道将完成构建工件的打包以进行部署。

本部分讨论了管道在执行由 Git 提交触发的所有必要活动中所起的作用。我们首先描述如何将 Jira 连接到外部 Git 服务器工具和外部管道工具，以实现持续集成。

然后，我们介绍了 Bitbucket Cloud。这个工具可以同时作为 Git 服务器和与 Bitbucket Pipelines 一起使用的管道工具。借助 Bitbucket Pipelines，我们探索了各种可用的功能，包括与测试和安全工具的连接，以及最终部署到不同的环境中。

本部分包括以下章节：

• 第四章，为设计、源代码管理和持续集成启用连接

• 第五章，理解 Bitbucket 和 Bitbucket Pipelines

• 第六章**, 扩展和执行 Bitbucket Pipelines

• 第七章**, 利用测试用例管理和安全工具进行 DevSecOps

• 第八章**, 使用 Bitbucket Pipelines 部署

• 第九章**, 利用 Docker 和 Kubernetes 进行高级配置

第四章：启用设计、源代码管理和持续集成的连接

Atlassian 的 Open DevOps 工具链的强大之处在于能够与许多外部第三方应用程序集成。尽管一个组织可能将 Atlassian 用作 DevOps 的骨干，但可能会有其他偏好的应用程序用于设计、源代码管理或持续集成（CI）。例如，虽然 Atlassian 可以轻松连接 Bitbucket 进行源代码管理和 CI，但我们可能希望连接到现有工具，如 GitHub 和 GitLab 进行源代码管理，以及 Jenkins 和 CircleCI 进行 CI。本章将演示如何将 Jira 与这些外部工具集成，以便在 Jira 中查看源代码管理和 CI 信息。

为实现这一目标，我们将参考以下方案：

• 将 Jira 与设计工具连接

• 使用原生集成将 Jira 与源代码管理连接

• 使用通用集成将 Jira 与源代码管理连接

• 将 Jira 与 CI 工具连接

技术要求

完成本章内容，你将需要以下内容：

• Jira

• Moqups 账户，访问 moqups.com/

• Figma 账户，访问 www.figma.com/

• GitLab 账户，访问 gitlab.com/

• CircleCI 账户，访问 circleci.com/

• 可用的本地 Jenkins 服务器，访问 www.jenkins.io/

将 Jira 与设计工具连接

可视化设计工具让设计师高效地创建线框图、模型和原型。通过创建这些详细的原型，你可以在编写任何代码之前识别可用性问题并进行必要的修改。例如，如果一个组织想开发移动应用程序，可以使用这些设计工具创建 UI 模型。然后可以将该模型附加到为跟踪此设计工作项而创建的Jira 问题中。

准备工作

要执行此方案，你将需要以下内容：

• Jira 管理员权限，以便安装必要的应用插件

• 你的 Moqups 账户

• 你的 Figma 账户

如何进行操作…

本方案的目标如下：

• 配置两个流行设计工具（Moqups 和 Figma）与 Jira 的集成

• 演示在 Jira 问题中使用设计工具

让我们开始实现这些目标。

如何将 Jira 连接到 Moqups

Moqups 是一个基于 Web 的应用程序，旨在促进线框图、模型、图表和原型的创建。这些是网站、软件和应用程序开发过程初期阶段的关键组成部分。

让我们开始将 Moqups 应用程序添加到 Jira 中。

1. 前往应用商店并搜索 Moqups 应用程序，选择 Moqups for Jira Cloud 应用程序。

图 4.1 – 寻找 Moqups 应用程序

1. 会显示一个应用信息页面。选择 获取应用 开始安装过程。

图 4.2 – 获取 Moqups 应用

1. 会出现一个 添加到 Jira 的弹出窗口。选择 立即获取 按钮以继续安装过程。

图 4.3 – 添加应用弹出窗口

1. 一旦应用安装完成并准备就绪，窗口将显示，允许您配置应用。选择 配置 选项。

图 4.4 – 配置 Moqups 应用

1. 要配置应用，您必须连接到现有的 Moqups 帐户。这将建立一个集成，允许您提取任何现有的 Moqups 项目。选择 连接到现有 Moqups 帐户 按钮。

图 4.5 – 连接到现有的 Moqups 帐户

1. 会显示一个 Moqups 凭证弹出窗口。输入您的 Moqups 帐户凭证并选择 连接 按钮。

图 4.6 – 输入 Moqups 凭证

1. 一旦您的 Moqups 凭证成功验证，您将看到 Moqups 应用信息 页面。在这里，您可以调整权限、订阅配额，或与 Moqups 断开连接。

图 4.7 – Moqups 配置设置

1. 现在 Moqups 已安装并配置完毕，我们可以将项目添加到任何 Jira 问题单中。为此，进入适当的 Jira 问题单并选择三个点以查看更多选项。选择 Moqups 选项。

图 4.8 – 选择 Moqups 以将组件添加到 Jira

1. 在 Jira 问题单中将提供一个 Moqups 部分。选择 添加 Moqups 项目 将一个项目拉入该问题单。

图 4.9 – 将 Moqups 项目添加到 Jira 问题单

1. 所有可用的 Moqups 项目将根据用户的权限显示。选择适当的项目，然后点击 添加 按钮。

图 4.10 – 选择并添加 Moqups 项目

1. Moqups 项目现在已作为对象嵌入在 Jira 问题单的 Moqups 部分中。

图 4.11 – Moqups 项目在 Jira 问题单上

1. 您现在可以直接在 Jira 问题单中编辑 Moqups 项目。选择 Moqups 对象中的铅笔图标，您将进入该项目的编辑模式。

图 4.12 – 编辑 Moqups 项目

做得好！你现在已经通过将 Moqups 设计应用与 Jira 集成，实现了本教程的目标。现在，你可以让设计团队和项目管理团队保持完全同步。

接下来，我们将进行一个类似的活动，但使用 Figma 设计应用。

如何将 Jira 连接到 Figma

Figma 是一款基于云的设计工具，以其协作功能和用户友好的界面广受欢迎。它主要面向应用程序的 UI 和 UX 设计，但它也具备强大的图形设计和原型制作功能。

接下来，我们将把 Figma 应用添加到 Jira，以展示另一个设计类应用程序。

1. 进入应用商店并搜索 Figma 应用。选择带有 Figma 标志的 Figma for Jira 应用。

图 4.13 – 安装 Figma 应用

1. 显示应用信息页面。选择 获取应用 开始安装过程。

图 4.14 – 安装 Figma 应用

1. 一个 添加到 Jira 的弹窗会出现。选择 立即获取 按钮继续安装过程。

图 4.15 – 安装 Figma 应用

1. 现在，切换到你现有的 Figma 账户，并选择你想要共享的项目。

2. 更新项目权限，允许用户查看和互动该文件。选择 复制链接 获取文件的 URL。

图 4.16 – 共享 Figma 项目

1. 切换回 Jira，并选择你想要将文件嵌入的 Jira 问题。选择更多选项中的三个点，并选择 设计。

图 4.17 – 从菜单中选择设计

1. 在 Jira 问题中会出现一个 设计 部分。粘贴复制的 Figma 文件 URL，并选择 添加设计。

图 4.18 – 添加 Figma 公共 URL

1. Figma 项目现在已添加到 Jira 问题的 设计 部分：

图 4.19 – Figma 项目现在嵌入到 Jira 问题中

你已经成功将 Figma 集成到 Jira！本教程展示了我们如何将设计活动融入到 Jira 问题管理中。

接下来，我们将介绍通过原生集成添加源代码控制应用程序。

使用原生集成将 Jira 连接到源代码控制

大多数源代码控制平台提供两种连接 Jira 的方式：原生连接（从源代码控制应用程序的角度）或使用 Atlassian 的 通用插件 管理器 (UPM) 安装插件。

在本节中，我们将了解如何使用本地集成连接 Jira 和GitLab。本地集成意味着我们直接从 GitLab 应用程序添加集成，而不是通过 Jira 端的应用程序。

GitLab 是一款流行的基于 Web 的 DevOps 生命周期工具，提供 Git 仓库进行源代码管理。GitLab 还具有 Wiki、CI/持续部署/交付（CD）和代码审查功能。它是一个完整的应用程序，允许开发人员和团队涵盖完整的软件开发生命周期（SDLC），从规划到创建、构建、验证、安全测试、部署和监控。

准备工作

要执行此操作，您需要一个 GitLab 账户，访问 gitlab.com/。

如何操作…

本教程的目标如下：

• 配置与 Jira 的本地 GitLab 集成

• 通过在 GitLab 中查看关联的 Jira 问题来验证连接

为了实现这些目标，我们将使用以下步骤：

1. 通过本地集成将 Jira 与 GitLab 连接，进入您的 GitLab 账户，并选择所需的项目：

图 4.20 – GitLab 项目

1. 在右侧菜单选项中，选择设置。

图 4.21 – GitLab 项目设置

1. 这将显示一个子菜单。从这里选择集成选项。

图 4.22 – GitLab 项目集成

1. 会显示可用集成的完整页面。向下滚动至 Jira 集成并选择配置。

图 4.23 – Jira 集成配置

1. Jira 连接详情将显示。要配置 Jira 端点，请完成以下操作。

   1. 勾选启用 集成选项。

   2. 在身份验证方法下，勾选基本，然后执行以下操作：

      1. 添加您的电子邮件或 用户名信息。

      2. 添加您的API Token 或 密码信息。

图 4.24 – Jira 连接参数

1. 向下滚动至 Jira 连接详情页面底部并执行以下操作：

   1. 勾选启用 Jira 问题。

   2. 添加您希望与此代码仓库项目关联的Jira 项目密钥值。

   3. 选择保存更改。

图 4.25 – 启用 Jira 问题

1. 在左侧菜单选项中，您现在可以选择计划，它将显示一个带有Jira 问题选项的子菜单。选择Jira 问题。

图 4.26 – 选择关联的 Jira 问题

1. 现在，您将看到与此 GitLab 仓库相关联的 Jira 问题。

图 4.27 – 查看与 GitLab 项目相关的 Jira 问题

您现在已成功通过 GitLab 原生集成功能将 Jira 集成到 GitLab 中。接下来，我们将探讨如何从 Jira UPM 添加源代码控制。

使用通用集成将 Jira 连接到源代码控制

将源代码控制连接到 Jira 的最简单方法之一是通过 Atlassian 的 UPM。

在本节中，您将学习如何通过GitHub等外部源代码控制工具建立连接，并使用 GitHub for Jira 应用查看来自 Jira 的已连接 Git 仓库数据。

GitHub 是一个基于云的平台，使用 Git 提供软件开发的源代码控制。GitHub 还为开发者提供错误追踪、任务管理和 CI/CD 功能。

准备工作

要执行此操作，您将需要以下内容：

• Jira 管理员权限，用于安装 GitHub for Jira 应用

• GitHub 账户：github.com/

操作方法…

本配方的目标是安装并配置 GitHub for Jira 应用程序。为此，请按照以下步骤操作：

1. 首先，我们需要将免费的 GitHub 应用安装到 Jira 中。

   前往应用市场，搜索 GitHub 应用。从 Atlassian 选择GitHub for Jira应用。

图 4.28 – 查找 GitHub for Jira 应用

1. 显示一个应用信息页面。选择获取应用以开始安装过程。

图 4.29 – 安装 GitHub 应用程序

1. 会弹出一个添加到 Jira的窗口。选择立即获取按钮以继续安装过程。

图 4.30 – 将 GitHub 应用添加到 Jira

1. 当 GitHub 应用程序安装完成并集成到 Jira 后，会弹出一个窗口，允许您通过选择开始使用来配置该应用程序。

图 4.31 – 配置 GitHub 应用程序

1. 显示一个连接 GitHub 到 Jira的界面。选择继续。

图 4.32 – GitHub 连接

1. 通过突出显示GitHub Cloud选项并选择下一步来授权 GitHub 链接。

图 4.33 – 选择 GitHub Cloud 或 GitHub 企业版服务器

1. Jira 需要 GitHub 的访问授权。选择授权 Jira。

图 4.34 – GitHub 配置说明

1. GitHub 访问的最后一步是选择连接。

图 4.35 – 连接 GitHub

1. 会出现一个响应页面，指示成功将 Jira 与 GitHub 集成。选择退出 设置。

图 4.36 – GitHub 连接

1. 会显示一个GitHub 配置页面，列出可用的已连接组织。

图 4.37 – 向 Jira 描述中添加 URL

恭喜你 – 你已经通过 UPM 过程将 GitHub 源代码控制集成进来了！

接下来，我们将探讨如何将 CI 工具添加到 Jira！

将 Jira 连接到 CI 工具

在本节中，我们将探讨如何将 Jira 与 CI 工具集成。结合 Jira 和 CI 可以为用户提供关于开发活动的详细视图，包括代码提交、拉取请求和发布。

准备开始

我们需要以下前置条件来完成本部分内容：

• Jenkins 服务器

• 已在 Jenkins 服务器上安装 Atlassian Jira 插件

• CircleCI 账户

• 来自 CircleCI 账户的组织 ID

如何操作……

我们将在本节中介绍两个操作步骤，首先是将 Jira 连接到 Jenkins，然后是将 Jira 连接到 CircleCI。

首先是 Jenkins。Jenkins 是一个流行的开源自动化服务器，允许开发人员持续构建、测试和部署他们的软件项目。Jenkins 服务器可以轻松地与 Jira 集成。

如何将 Jira 连接到 Jenkins

让我们从添加 Jenkins 应用开始。

1. 进入应用商店并搜索 Jenkins 应用。选择Jenkins for Jira (****官方)应用。

图 4.38 – 查找 Jenkins for Jira 应用

1. 显示应用程序信息页面。选择获取应用以开始安装过程。

图 4.39 – 获取 Jenkins for Jira 应用

1. 会弹出一个添加到 Jira的窗口。选择立即获取按钮以继续安装过程。

图 4.40 – 安装 Jenkins for Jira 应用

1. 一旦 Jenkins 应用程序安装完成，我们就可以开始配置。导航至 Jira 的管理应用页面，并从左侧菜单中选择Jenkins for Jira项。

图 4.41 – 配置 Jenkins for Jira 应用

1. 会显示一个将 Jenkins 连接到 Jira 软件页面。选择连接 Jenkins 服务器按钮继续配置。

图 4.42 – 连接到 Jenkins 服务器

1. 配置过程中会提示Atlassian Jira Software Cloud插件应该已经安装在 Jenkins 服务器上。继续点击下一步按钮。

图 4.43 – 确认 Jira 插件已安装在 Jenkins 上

1. 我们可以通过首先为 Jenkins 服务器连接提供一个名称，然后选择创建来开始创建连接。

图 4.44 – 创建 Jenkins 服务器连接

1. Jenkins for Jira 应用将为您提供 Webhook URL 和密钥。这些参数是您需要复制并粘贴到将 Jenkins 连接到您的 Jira 站点配置中的内容。

   选择完成。

图 4.45 – Jenkins 连接参数

Jenkins for Jira 应用现在会显示连接的 Jenkins 服务器。

图 4.46 – Jenkins 已连接

Jenkins 是最流行的 CI 工具之一，您现在已经成功将该应用连接到您的 Jira 实例。

接下来，我们来看一下如何集成另一个流行的 CI 工具：CircleCI。

如何将 Jira 连接到 CircleCI

CircleCI是一个现代化的 CI/CD 平台，能够自动化软件开发过程，让团队能够快速且可靠地构建、测试和部署应用。它旨在与云端或本地的版本控制系统（VCSs），如 GitHub 和 Bitbucket 一起使用。

让我们开始将 CircleCI 应用添加到 Jira。

1. 首先，前往应用市场并搜索 CircleCI 应用。选择CircleCI for Jira应用。

图 4.47 – 查找 CircleCI for Jira 应用

1. 显示应用信息页面。选择获取应用以开始安装过程。

图 4.48 – 获取 CircleCI for Jira 应用

1. 一个添加到 Jira的弹窗会显示出来。选择立即获取按钮以继续安装过程。

图 4.49 – 安装 CircleCI for Jira 应用

1. 一旦安装了 CircleCI 应用，我们可以开始配置。前往 Jira 的管理应用页面，并从左侧菜单中选择CircleCI for Jira项目。

图 4.50 – 管理 CircleCI for Jira 应用

1. 一个CircleCI for Jira配置页面将显示出来；选择配置。

图 4.51 – 配置 CircleCI for Jira 应用

1. CircleCI 将请求访问 Atlassian 产品的权限；选择允许访问。

图 4.52 – 允许 CircleCI 访问

1. 一旦获得 Atlassian 产品的访问权限，CircleCI 应用将请求访问您的 Atlassian 账户。选择接受。

图 4.53 – 接受访问请求

一个CircleCI for Jira – 配置页面将显示出来。

图 4.54 – CircleCI for Jira 配置页面

1. 为完成配置，我们需要获取 CircleCI 组织 ID。为此，切换到你的 CircleCI 账户并选择 组织设置 菜单选项。

图 4.55 – CircleCI 组织设置菜单选项

1. 将显示一个组织 概述 页面，其中包含 组织 ID 值。点击 组织 ID 值旁边的复制图标。

图 4.56 – CircleCI 组织 ID 值

1. 将组织 ID 复制到剪贴板后，切换回你的 Jira 应用。将组织 ID 粘贴到 CircleCI 组织 ID 字段中，然后选择 提交。

图 4.57 – 提交 CircleCI 配置

现在可以通过 Web 触发器 URL 值配置 CircleCI Jira orb，以传递有关构建或部署的信息。请查看以下截图，了解如何复制 Web 触发器 ID。

图 4.58 – 提交 CircleCI 配置

本食谱的范围并不包括完整构建 CircleCI 管道，但它展示了如何将 CircleCI 应用与 Jira 集成。有关如何使用 Web 触发器 URL 完成 CircleCI 管道的更多信息，请参阅以下网站：circleci.com/developer/orbs/orb/circleci/jira。

第五章：理解 Bitbucket 和 Bitbucket Pipelines

Bitbucket 是 Atlassian 的源代码管理（SCM）解决方案，帮助开发人员对源代码进行版本控制。Bitbucket 与 Jira 紧密集成，允许开发人员协作编写代码并与利益相关者共享状态。Bitbucket 不仅仅存储和跟踪变更，它还提供了一个强大的部署系统，称为Bitbucket Pipelines。通过 Pipelines，开发人员可以轻松地构建并将代码部署到不同的环境。此外，runners 是执行构建和部署的机器。Bitbucket Pipelines 可以使用其 runners 来执行管道任务，根据执行所需的时间与月度预算进行计费，或者开发人员可以定义自托管的 runners，使用他们自己的基础设施来执行任务。

本章节包含以下教程 – 第一个教程将带您了解基础知识，后续教程将在此基础上扩展：

• 在 Bitbucket 中创建工作区、项目和代码库

• 在 Bitbucket 中创建分支

• 理解拉取请求和合并最佳实践

• 启用 Bitbucket Pipelines

• 配置 Bitbucket 中的 runners

技术要求

您需要以下软件：

• 带有代码库的 Bitbucket Cloud

• Bitbucket runners

在 Bitbucket 中创建工作区、项目和代码库

与 Jira 或 Confluence 相比，Bitbucket 是一个非常不同的工具。与几乎不需要配置即可开始使用的 Jira 和 Confluence 不同，Bitbucket 在团队使用之前需要一些前期的技术配置。本教程重点帮助您了解 Bitbucket 的结构，并解释启用 Bitbucket 所需的各种初始配置步骤。

如何操作…

当首次配置 Bitbucket 时，您需要首先创建一个工作区。工作区包含代码库，后续将在本教程中讨论。当您登录 Bitbucket 后，您会看到您可用的工作区，如下图所示：

图 5.1 – Bitbucket 中可用工作区概览

重要提示

在您首次注册 Bitbucket 时，可能已经创建了一个初始工作区。在这种情况下，您可以跳到下一部分，或者如果您想创建一个全新的工作区，请继续操作。此外，确保您已登录 Bitbucket，并且是 Bitbucket 的管理员。

要创建一个工作区，请执行以下步骤：

1. 点击 Bitbucket 右上角的个人资料图标。

图 5.2 – 选择个人资料图标

1. 点击所有工作区，位于最近的工作区下。

图 5.3 – 选择所有工作区

1. 点击 创建工作区，该按钮位于 Bitbucket 用户界面的右上角。

图 5.4 – 创建工作区按钮

1. 输入工作区名称。

图 5.5 – 提供新工作区的名称

重要提示

这将自动填充 工作区 ID。您可以选择更改它或保留 Atlassian 提供的默认值。工作区 ID 将作为您创建的新工作区的 URL。

1. 更新 工作区 ID。

图 5.6 – 工作区 ID

1. 确定您是否希望工作区保持私有，或者希望将其设置为公开，可以通过选中复选框来选择。

图 5.7 – 确定工作区是否应该是私有的还是公开的

1. 在验证 reCAPTCHA 后，点击 创建 按钮：

图 5.8 – 创建您的第一个工作区

现在您的工作区已创建，您将能够创建您的第一个仓库。

还有更多内容…

一旦进入新的工作区，就可以开始创建您的第一个仓库了。仓库是存放源代码的地方。在一个工作区内，您可以拥有多个仓库。接下来，按照以下步骤来创建仓库：

1. 点击 创建仓库，该按钮位于欢迎消息中或 最近的仓库 下方。

图 5.9 – 创建您的第一个仓库

1. Bitbucket 会将您重定向到一个新页面，您将在此页面首先提供项目名称。仓库被分组到项目中，因此首先提供项目名称是很重要的：

图 5.10 – 创建您的第一个仓库并提供项目名称

1. 接下来，提供您的仓库名称。这应该是对使用该仓库的团队有意义的名称：

图 5.11 – 提供仓库名称

1. 确定仓库是否应该是私有的还是公开的。

图 5.12 – 确定仓库的访问级别

1. 确定仓库中是否应包含README文件，是否包含模板，或者是否包含适合初学者的教程，建议选择教程。

图 5.13 – 确定仓库中是否包含 README 文件

1. 提供默认分支的名称。通常是main或master。

图 5.14 – 默认分支名称

1. 最后，确定是否应该包含 .gitignore 文件。如果您的项目中有一些文件或目录不需要被 Git 跟踪，建议包含一个 .gitignore 文件。这些文件或目录将被忽略，不会被提交到仓库中。

图 5.15 – 确定是否包含 .gitignore 文件

1. 点击位于屏幕右下角的 创建仓库 按钮。无需担心配置任何高级设置。

图 5.16 – 创建仓库按钮

您的第一个工作区、项目和仓库已经创建完成。在接下来的教程中，您将学习如何在 Bitbucket 中开始创建分支。

在 Bitbucket 中创建分支

在 Bitbucket 中直接使用默认分支并不是最佳实践，因为它会影响主代码库，而主代码库应该尽可能保持稳定。相反，您应该考虑在 Bitbucket 中使用分支，本教程将涵盖分支的基础知识。在分支策略方面有不同的技术，本教程将简单介绍创建分支的基本操作。

准备工作

在深入探讨如何在 Bitbucket 中创建分支之前，让我们先讨论一下不同类型的分支。在 Git 的世界里有不同的分支策略。在这个示例中，将使用 Gitflow 来说明分支是如何工作的。Gitflow 是由 Atlassian 详细记录的，因此在本教程中将使用 Gitflow 来解释分支策略：

• 主分支：主分支应该是您仓库中最稳定的分支。这意味着主分支中的代码应该是最完整、最稳定的版本。通常，主分支用于创建发布版本并部署到生产系统，因此这是最稳定的分支。

• 开发：这是遵循 Gitflow 方法论时非常常见的一个分支。开发分支是您的团队将其更改集成到的分支，或者是他们从中创建特性分支的地方。开发分支最初是从主分支分出的。

• 特性：每当一个任务被分配给 Jira 中的开发人员时，该开发人员应该创建一个特性分支，该分支应基于 develop 分支。特性分支是短暂的，一旦开发人员完成代码，应该启动一个拉取请求，将更改合并回 develop 分支。

• 发布：每当开发分支准备好发布到生产环境时，会从最新的开发分支创建一个发布分支。该发布分支在合并回主分支和开发分支之前，应该经过测试和验证。

• 热修复：当生产系统出现问题时，应创建热修复分支来解决主分支中发现的代码问题。

现在你已经了解了 Gitflow 模型中的各种分支，我们将介绍如何在 Bitbucket 中创建分支。

如何操作…

在 Bitbucket 中，分支操作非常直接，但它通常不是最受欢迎的选项。如果你是源代码管理系统的新用户，那么使用像 Bitbucket 这样的用户界面可能是一个不错的选择：

1. 在 Bitbucket 中，进入你想要创建分支的仓库。点击导航栏中的仓库。

图 5.17 – 从菜单栏中选择仓库

1. 选择你想要创建分支的仓库。

图 5.18 – 从可用仓库中选择你想要的仓库

这将带你进入主仓库窗口。

图 5.19 – 已选择的仓库

1. 点击左侧菜单中的分支。

图 5.20 – 从选定的仓库中选择分支

1. 在屏幕的右上角，点击创建分支。

图 5.21 – 选择创建分支

1. 选择分支类型，并确定此新分支将从哪个分支派生。为新分支命名。完成后，点击创建。

图 5.22 – 创建新分支示例

你已经成功创建了第一个分支。接下来的内容将介绍当你完成代码更改后会发生什么，以及这些更改如何与团队中的其他成员共享。

理解拉取请求和合并最佳实践

跟踪分支和代码更改是 Bitbucket 内置的功能之一。当你完成代码更改后，这些更改需要合并回上游分支。如果你遵循 Gitflow 模型，那么意味着所有代码更改都是在专用的功能分支中完成的，现在是时候将这些更改合并回开发分支了。这个合并的过程称为拉取请求。拉取请求不仅仅是合并代码更改。接下来的内容将解释如何使用拉取请求来维护高质量的代码，并最大程度地减少新代码更改破坏系统的可能性。

如何操作…

完成更改后，是时候发起拉取请求了。这个拉取请求将触发一系列事件，后续步骤中将详细说明：

1. 在 Bitbucket 中，输入你想要创建分支的仓库。在导航栏中点击仓库。

图 5.23 – 从菜单栏选择仓库

1. 选择你想要创建分支的仓库。

图 5.24 – 从可用仓库中选择你选择的仓库

这将带你到主仓库窗口。

图 5.25 – 选择的仓库

1. 点击左侧菜单中的拉取请求。

图 5.26 – 从选定的仓库中选择拉取请求

重要提示

开始拉取请求有很多种方法。你可以在提交更改时启动它。你也可以通过点击 Bitbucket 导航栏中的创建按钮来启动它。你还可以通过分支菜单启动拉取请求。更不用说，你还可以通过命令行和 Jira 启动拉取请求。本文描述的方法是从 Bitbucket 内部创建拉取请求的最全面的方法。

1. 在最右侧，点击创建 拉取请求。

图 5.27 – 点击创建拉取请求

你将被重定向到一个屏幕，在该屏幕中你可以填写创建拉取请求所需的所有详细信息。

1. 首先选择源分支。这应该是你正在工作的功能分支。

图 5.28 – 选择源分支

1. 选择代码更改应该合并到的目标分支。这应该是Develop分支：

图 5.29 – 选择目标分支

1. 给拉取请求起个标题。你可以根据需要随意命名，但作为最佳实践，标题中应包括你正在处理的用户故事/缺陷的 Jira 键。

图 5.30 – 拉取请求名称

1. 添加描述，最好能描述你的更改以及任何可能对审查者有帮助的内容。

图 5.31 – 为拉取请求提供描述

1. 下一步是最关键的。每个拉取请求都应该由团队中的其他人进行审查。这可以是其他同行，但最好至少有一名高级开发人员来审查拉取请求。

图 5.32 – 选择应该审查拉取请求的团队成员

1. 可选地，确定是否在合并后让 Bitbucket 删除该分支。通常这是一个好主意，因为 Bitbucket 会通过删除那些已经合并的、不再需要的分支，帮助保持你的分支整洁。

图 5.33 – 确定合并后是否删除源分支

重要提示

在创建拉取请求之前，回顾一下由于你所做的更改而受到影响的提交和文件。这应该作为你个人的检查，确保拉取请求中没有遗漏提交或文件/更改。

1. 最后，点击 创建拉取请求 以发起拉取请求。

图 5.34 – 为拉取请求提供描述

现在拉取请求已经正式创建，是时候让某人进行审查了。一旦审查完成，代码就可以被批准合并到目标分支中。在下一章节中，我们将介绍如何在 Bitbucket 中配置你的第一个管道。

启用 Bitbucket Pipelines

在所有更改都经过批准并合并到开发分支后，它们需要被构建和部署。部署你的更改很重要，因为你的源代码最终需要运行在一个环境中，在这个环境里，最终用户能够使用你构建的功能。你可以手动将文件从你的计算机复制到另一台计算机，但这种做法不可扩展，且在我们生活的分布式世界中很可能不可行。相反，你可以利用 Bitbucket Pipelines 的强大功能来自动部署代码。

如何操作…

在你能够使用 Bitbucket Pipelines 之前，你需要调整一些设置：

1. 在 Bitbucket 中，进入你想要创建分支的仓库。点击导航栏中的 Repositories。

图 5.35 – 从菜单栏中选择仓库

1. 选择你想要在其中创建分支的仓库。

图 5.36 – 从可用仓库中选择你喜欢的仓库

这将带你进入主仓库窗口。

图 5.37 – 选择的仓库

1. 点击左侧菜单中的 Pipelines。

图 5.38 – 从选定的仓库内选择 Pipelines

1. 点击 创建你的第一个管道，这将引导你查看可供选择的模板。

图 5.39 – 创建你的第一个管道

1. 选择 Starter pipeline。

图 5.40 – 推荐使用起始管道

配置你的第一个管道是一个复杂的过程。在接下来的部分中，我们将逐步解析起始模板，并解释你可以在 Bitbucket 的管道编辑器中对模板进行的各种调整。

还有更多…

有许多配置需要设置。本节将概述这些更改。在下一章中，你将学习如何扩展这个相当简单的管道配置文件：

1. 第一个可以更改的配置是 bitbucket-pipelines.yml 文件的模板。在上一部分的 步骤 5 中，我们选择了 bitbucket-pipelines.yml 文件，确保你处于编辑模式，你会看到可以更改模板的位置。

图 5.41 – 可用的管道模板

重要提示

根据你选择的模板，模板中的信息将会有所变化。

1. 默认情况下，你选择的模板会根据所选模板类型包含推荐的步骤。如果你需要添加新的步骤，可以通过选择可用的步骤类型来实现。

图 5.42 – 可用的步骤类型

1. 选择你想要添加的步骤，弹出窗口会显示，允许你复制信息，以便将其添加到你的模板中。

图 5.43 – 额外的步骤信息以供复制

重要提示

步骤 3 仅展示了如何向管道中添加一个步骤。理想情况下，你还想为构建和打包创建步骤。你也可以考虑加入测试、扫描、交付等步骤。

1. 一旦复制到剪贴板，你可以将额外的步骤添加回你的模板中：

图 5.44 – 添加了部署步骤

1. 你还可以将集成添加到管道配置中。

图 5.45 – 可用的管道集成

重要提示

你可以点击 探索更多管道 来查看所有可用的集成。根据你的特定需求，有数十个集成可以选择。

1. 最后，你可以向 bitbucket-pipelines.yml 添加变量，使你的管道更加通用、可配置和可重用。

图 5.46 – 向管道模板添加变量

1. 一旦你完成修改管道模板后，可以通过点击屏幕底部的 提交 按钮将文件提交回你的代码库。

图 5.47 – 提交 bitbucket-pipelines.yml 文件

1. 然后，你的管道将执行。在提交后，你将被重定向回 Pipelines 菜单，在那里你可以看到管道的状态。如果需要，我建议将管道合并回主分支或开发分支。

图 5.48 – 管道状态

1. 点击你的管道执行记录以获取有关最新构建运行的详细信息：

图 5.49 – 管道运行执行详情

1. 返回 Pipelines 菜单，你可以通过点击 Run pipeline 按钮触发管道运行。

图 5.50 – 强制运行管道

1. 选择你要运行的分支和管道。

图 5.51 – 运行管道详情

1. 你还可以安排管道在特定时间运行。

图 5.52 – 安排管道

1. 最后，你可以查看你的使用情况，因为 Bitbucket 管道是按运行管道所需的分钟数来跟踪的。每月可用的时间量由你的 Bitbucket 订阅计划决定。

图 5.53 – 查看管道使用情况

这只是 Bitbucket 中管道的简介。在下一章中，你将学习如何创建更高级的 Bitbucket 管道。

在 Bitbucket 中配置运行器

在 Bitbucket Cloud 中，你必须为每一分钟的构建付费。这会迅速增加费用，因此，作为替代方案，你可以使用自托管运行器。运行器允许你节省构建分钟数，但你需要在你的基础设施中维护它们。

如何操作…

运行器将帮助你降低 Bitbucket 成本，但它们确实需要一些初始配置，以下步骤会对此进行介绍：

1. 在 Bitbucket 中，进入你想要创建分支的仓库。点击导航栏中的 Repositories。

图 5.54 – 从菜单栏选择仓库

1. 选择你想要创建分支的仓库。

图 5.55 – 从可用仓库中选择你需要的仓库

这将带你进入主仓库窗口。

图 5.56 – 已选择的仓库

1. 进入你想要添加运行器的仓库后，点击左侧菜单中的 Repository settings。

图 5.57 – 选择仓库设置

重要说明

每个仓库最多只能有 100 个运行器。

1. 进入 Repository settings 后，向下滚动，直到找到 PIPELINES 部分。然后点击 Runners。

图 5.58 – 在 PIPELINES 下选择 Runners

1. 点击添加运行器以添加自托管运行器。

图 5.59 – 添加运行器

1. 选择新运行器的系统和架构类型。有几种不同的选项，您应选择最适合您计划使用的运行器类型的选项。

图 5.60 – 选择系统和架构类型

1. 给您的运行器命名。

图 5.61 – 为运行器提供名称

1. 提供运行器标签。

图 5.62 – 提供运行器标签

重要提示

您最多可以提供 10 个运行器标签。使用这些标签帮助安排运行器的执行时间。标签只能包含小写字母、数字和点。

1. 点击下一步按钮。

图 5.63 – 点击“下一步”按钮继续

1. 在下一个屏幕上，复制显示的命令。

图 5.64 – 启动和配置运行器所需的命令

重要提示

您将无法在之后获取该命令信息，因此请确保将其保存在安全的位置。您将需要这个命令来安装和配置您的运行器。

1. 点击下一步按钮。

图 5.65 – 点击“下一步”继续到下一个步骤

1. 复制标签并将其添加到您的bitbucket-``pipelines``.yml文件中。

图 5.66 – 复制标签以包含在 YAML 文件中

1. 点击完成按钮完成运行器的创建。

图 5.67 – 点击“完成”创建运行器

重要提示

您的运行器现在将在您的仓库中可用，但在您运行来自第 9 步的命令启动运行器之前，它将不会注册。在下一个食谱中，您将演示如何创建一个有效且可用的运行器。

1. 您新创建的运行器，将处于未注册状态，并会在 Bitbucket 中的运行器菜单中可见。

图 5.68 – 仓库中可用运行器的列表

现在您已经有了一个自托管的运行器，您可以节省构建时长费用。如果您消耗了大量的构建时长，虽然需要托管您自己的运行器，但这可能是节省一些费用的有效方式。

第六章：扩展和执行 Bitbucket Pipelines

在 第五章中，我们首先介绍了 Bitbucket Cloud，这是一个基于云的 源代码管理（SCM）工具，来自 Atlassian，其中包括 Bitbucket Pipelines。Bitbucket Pipelines 支持 持续集成 和 部署，源代码在提交后会自动进行构建、测试和部署。

本章将首先介绍使用 Bitbucket Pipelines 进行持续集成。通过将第三方工具集成到 Bitbucket Pipelines 中，您将扩展对其的了解，这些工具用于进行语法检查和安全测试。您还将定义并配置执行 Bitbucket Pipelines 的运行器和代理。 本章中的配方包括以下内容：

• 配置管道选项

• 管道的条件执行

• 手动执行

• 定时执行

• 定义变量

• 为管道定义运行器

• 连接到 Bitbucket Pipes

• 在 Bitbucket Pipelines 中测试步骤

• Bitbucket Pipelines 中的安全步骤

• 报告测试结果

让我们从查看 Bitbucket Pipelines 的结构开始，来进行初步分析。

技术要求

本章中的配方需要在工作区、项目和仓库中设置 Bitbucket Cloud。此外，自托管运行器需要运行 Linux、macOS 或 Windows 的机器。

本章的示例代码可以在本书 GitHub 仓库的 Chapter6 文件夹中找到（github.com/PacktPublishing/Atlassian-DevOps-Toolchain-Cookbook/tree/main/Chapter6）。

配置管道选项

本配方将向您展示 bitbucket-pipelines.yml 文件的一般结构和配置选项。我们在 第五章中创建了描述管道执行的文件（bitbucket-pipelines.yml）。现在让我们来看一下 bitbucket-pipelines.yml 中的配置。

以下代码片段详细列出了可能的配置示例以及 bitbucket-pipelines.yml 文件的一般结构：

options:
  Global options are here (not required – this section may be absent)
clone:
  Configurations for Git clone behavior go here
definitions:
  Cache and service container definitions here
image:
  Docker image options are here (Chapter 9)
pipeline:
  Pipeline start options are here
    parallel:
      Parallel step options go here
    stage:
      Stage options are here
    step:
      Step options are here

本配方将向您展示管道的一般配置选项。随后的配方将演示如何应用前述代码片段中概述的选项。

如何操作…

我们将在本配方中评估以下配置部分：

• 全局选项

• git clone 行为

• definitions

随后的配方将讨论管道执行选项的配置。

配置全局选项

全局选项指定所有执行管道的行为。全局选项包括以下内容：

• docker

• max-time

• size

让我们逐一检查这些选项：

• 如果您希望您的管道运行 Docker 命令，请指定 docker 关键字，并将其值设置为 true，如以下代码片段所示（我们将在 第九章 中详细讨论）：

  options:
     docker: true
  

• 如果您需要为步骤执行分配更多时间，以避免超时，请指定 max-time 关键字，并设置一个介于 1 和 120 之间的整数。该数字表示等待时间，单位为分钟。max-time 选项也可以在步骤级别使用，以设置该步骤的超时时间。以下代码片段将管道中所有步骤的最大时间设置为 5 分钟：

  options:
     max-time: 5
  

• size 选项可以为整个管道或单个步骤分配额外内存。如果您使用的是 Bitbucket Cloud 上的运行器，选项为 1x 和 2x，而自托管的 Docker 运行器则有 1x、2x、4x 和 8x 的选项。以下代码片段将整个管道的大小设置为正常配额的两倍：

  options:
     size: 2x
  

我们已经了解了如何配置与运行 Docker 命令、等待时间和可用运行器内存相关的全局选项。现在让我们看看在管道中执行 git clone 操作时配置行为的选项。

git clone 行为

bitbucket-pipelines.yml 中的 clone: 部分控制通过 git clone 操作复制仓库。它可以放置在 options: 部分之后，以配置整个管道的 git clone 行为，或放置在 step: 部分中，以配置该步骤的 git clone 行为。可用的选项列出如下：

• depth：此选项控制克隆操作的深度。

• lfs：这允许支持 Git 大文件系统（LFS）文件。

• enabled：此选项启用或禁用 git clone 操作。

• skip-ssl-verify：这允许跳过单个步骤的 安全套接字层（SSL）验证。

让我们逐一深入了解这些选项：

• 您可以通过添加 enabled 关键字并将其值设置为 true 来启用 git clone 操作，或者将其值设置为 false 来禁用该操作，具体范围指定如下。以下示例演示了如何禁用所有管道步骤的克隆操作：

  clone:
     enabled: false
  pipelines:
     default:
        - step:
            script:
               - echo "Cloning not done"
  

• 要控制 git clone 操作中包含的提交数量，请使用 depth 关键字，值为 full 表示完整克隆操作，或者使用一个正整数表示要在 git clone 操作中包含的提交数量。此功能设置了快速检出，不需要完整历史记录，特别适用于大型仓库。以下代码片段演示了一个克隆操作，该操作克隆了所有管道步骤中的最后五个提交：

  clone:
     depth: 5
  pipelines:
     default:
        - step:
            script:
              - ls $BITBUCKET_CLONE_DIR
  

• 使用 lfs 选项并将其值设置为 true，可以在每个步骤开始时下载所有 LFS 文件（如果全局设置）。如果将其放在某个步骤内，所有 LFS 文件的下载将在该步骤开始时开始。以下代码片段演示了在每个步骤中下载所有 LFS 文件：

  clone:
     lfs: true
  pipelines:
     default:
        - step:
            name: Download LFS
            script: "Cloning and downloading..."
  

• skip-ssl-verify选项仅在单个步骤的作用域内有效，并且只适用于自托管的管道运行器。将此选项设置为true将禁用该步骤的 SSL 验证，允许使用自签名证书。以下代码片段展示了这一点：

  pipelines:
     default:
        - step:
            runs-on:
               - 'self.hosted'
            clone:
               skip-ssl-verify: true
            script:
               - echo "Using self-signed certificate"
  

我们现在已经了解了git clone操作的所有管道步骤或单个管道步骤可用的选项。接下来，我们将看看如何通过配置definitions部分将资源包含到管道中。

配置定义

definitions部分描述了所有管道步骤可用的额外资源。以下列表概述了可用资源的类型：

• 缓存

• 服务

• YAML 锚点

我们将在第九章中讨论如何使用 Docker 容器配置服务。缓存允许暂时存储构建依赖项及其目录。让我们看看缓存的用途：

1. 在definitions部分，你可以通过文件名或目录路径来定义缓存。路径可以包括作为通配符表达的模式。以下代码片段展示了我们如何为 Ruby 构建定义并使用缓存：

   definitions:
     caches:
       my-bundler-cache: vendor/bundle
   pipelines:
     default:
       - step:
           caches:
             - my-bundler-cache # Cache is defined above in the definitions section
           script:
             - bundle install --path vendor/bundle
             - ruby -e 'print "Building on Ruby"'
   

2. 可以在caches定义块中的key部分指定需要监视更改的文件列表，并在files关键字下列出。多个文件可以使用通配符字符在 glob 模式中指定。files的位置将由path选项指定。以下代码片段展示了如何使用key、files和path关键字为 Ruby 构建实现缓存定义：

   definitions:
     caches:
       my-bundler-cache:
         key:
           files:
             - Gemfile.lock
             - "**/*.gemspec" # glob patterns are supported for cache key files
         path: vendor/bundle
   pipelines:
     default:
       - step:
           caches:
             - my-bundler-cache # Cache is defined above in the definitions section
           script:
             - bundle install --path vendor/bundle
             - ruby -e 'print "Hello, World\n"'
   

3. YAML 锚点允许重用 YAML 行块。锚点字符（&）定义可重用的块。别名字符（*）作为指令使用引用。以下代码片段展示了如何使用 YAML 锚点重用步骤定义：

   definitions:
     steps:
       - step: &package
           name: Build and test
           script:
             - mvn package
           artifacts:
             - target/**
   pipelines:
     default:
       - step: *package
   

重要说明

YAML 锚点和别名的名称不能包含以下字符：'['、']'、'{'、'}'和','。

另见

以下链接提供了有关缓存的更多详细信息，特别是在使用标准语言和工具构建时可用的预定义缓存：

• support.atlassian.com/bitbucket-cloud/docs/cache-dependencies/#Pre-defined-caches

• support.atlassian.com/bitbucket-cloud/docs/use-glob-patterns-on-the-pipelines-yaml-file/

我们已经看到如何在管道上全局配置选项。现在我们准备好检查管道结构中更模块化的部分。

条件执行管道

我们从指定管道的定义选项转向指定管道的执行。这要求我们查看管道结构的以下部分：

• 管道

• 并行

• 阶段

• 步骤

我们将在以下用例中看到这些部分如何受到影响：

• 提交到一个分支

• 创建拉取请求

• 创建标签

在我们检查用例之前，让我们先看看结构。

准备工作

bitbucket-pipelines.yml文件中的pipelines部分定义了所有可用的流水线定义，用于构建和部署。它在文件中只定义一次，并且是必需的。

在pipelines部分中，有一些定义了基于前面部分提到的条件使用案例的流水线。一个流水线可以看作是由step关键字定义的一系列步骤。流水线的步骤数量最多为 100 个。

步骤至少需要包含在定义为构建环境的 Docker 容器中运行步骤的命令。这些命令包含在必需的script部分中。此外，还可以在step部分中定义其他选项，以进一步定义步骤的行为。以下代码片段展示了一个简单的单命令步骤示例：

pipelines:
   default:
      - step:
          script:
             - echo "Running a command"

步骤通常是按顺序执行的。如果要并行执行多个步骤，可以使用parallel关键字将步骤组合在一起。一种常见的用例是允许测试步骤并行执行。以下代码片段展示了一个示例：

pipelines:
  default:
    - step:          # non-parallel build step
        script:
          - ./build.sh
    - parallel:      # these 2 steps will run in parallel
        steps:
          - step:
              script:
                - ./integ-tests.sh --batch 1
          - step:
              script:
                - ./integ-tests.sh --batch 2
    - step:          # non-parallel deploy step
        script:
          - ./deploy.sh

阶段（stage）是步骤的分组，以便执行某个特定功能。阶段部分由stage关键字定义，并在steps关键字下包括其步骤。阶段有助于定义构建、测试、打包和发布等不同阶段的步骤。阶段的一个用途可能是在部署过程中，它可以显示部署的哪个部分失败，并允许使用公共环境和环境变量。以下代码片段展示了一个阶段示例：

pipelines:
   default:
      - stage:
          name: build/test
          steps:
            - step:
                name: Build step
                script:
                   - sh ./build-app.sh
            - step:
                name: Unit-test
                script:
                   - sh ./run-unit-tests.sh

default部分定义了在每次推送到仓库时要运行的流水线步骤，除非推送发生在定义的特定分支流水线中，或者推送基于git tag操作。让我们重新审视我们的单步流水线示例，看看由于default关键字的存在，它将始终运行：

pipelines:
   default:
      - step:
          script:
             - echo "Running a command"

现在我们通过pipelines、parallel、stage和step部分理解了流水线的基本结构，让我们看看在什么情况下我们希望条件性地执行流水线步骤。

如何实现…

本食谱的准备工作部分展示了bitbucket-pipelines.yml文件中的流水线结构。pipelines、parallel、stage和step部分允许无条件执行流水线步骤。

现在我们想要根据以下用例运行不同的流水线步骤：

• 提交到特定分支

• 创建拉取请求

• 创建特定标签

Bitbucket Pipelines 通过额外的部分，使用特定的关键字，允许这些条件性用例的出现。让我们逐一检查这些关键字：

• branches关键字允许指定执行管道步骤的具体分支。分支可以通过其名称标识，或者使用 glob 模式将其分组。在这种情况下，default 关键字表示那些针对未在 branches 部分定义的分支执行的步骤。以下代码片段展示了一个管道，其中包含针对主分支和任何特性分支的不同步骤：

  pipelines:
    default:
      - step:
          script:
            - echo "This script runs on all branches that don't have any specific pipeline assigned in 'branches'."
    branches:
      main:
        - step:
            script:
              - echo "This script runs only on commit to the main branch."
      feature/*:
        - step:
            script:
              - echo "This script runs only on commit to branches with names that match the feature/* pattern."
  

• 针对拉取请求的管道是基于工作分支和 pull-requests 关键字来定义的。这些管道定义了在向目标分支创建拉取请求时要执行的特定步骤。工作分支可以使用 glob 模式组合成类似的分支类别。执行拉取请求管道会在运行前将目标分支合并到工作分支中。如果合并失败，管道执行将会停止。以下代码片段展示了针对特性分支和热修复分支的拉取请求管道：

  pipelines:
    pull-requests:
      feature/*:
        - step:
            name: Build for pull request to feature branch
            script:
              - echo "feature branch PR!"
      hotfix/*:
        - step:
            name: Build for pull request to hotfix branch
            script:
              - echo "hotfix PR!"
      '**':
        - step:
            name: Build for all pull requests to other branches
            script:
              - echo "all other non-feature, non-hotfix pull request!"
  

• 要设置基于标签的管道，可以使用 tags 关键字来表示在 git tag 匹配 tags 部分中定义的模式时要执行的步骤。注意，glob 模式可以应用于搜索参数，以扩大标签的搜索范围。以下代码片段根据搜索中匹配的标签来运行管道操作：

  pipelines:
    tags:
      '*-FirstTag':
        - step:
            name: Build for *-FirstTag tags
            script:
              - echo "First tag!"
      '*-SecondTag':
        - step:
            name: Build for *-SecondTag tags
            script:
              - echo "Second tag!"
      '*-ThirdTag':
        - step:
            name: Build for *-ThirdTag tags
            script:
              - echo "Third tag!"
  

我们已经了解了如何根据分支、是否创建拉取请求以及是否创建标签来设置有条件运行的管道。

另见

以下链接提供了更多关于我们在本篇食谱中讨论的部分的详细信息：

• support.atlassian.com/bitbucket-cloud/docs/step-options/

• support.atlassian.com/bitbucket-cloud/docs/stage-options/

• support.atlassian.com/bitbucket-cloud/docs/parallel-step-options/

到目前为止，我们讨论了在提交或拉取请求操作发生时自动运行的管道执行。我们能手动运行管道吗？当然可以！接下来，我们将探讨如何做到这一点。

手动执行

尽管通常情况下，管道会在提交或拉取请求时自动执行，但也可以手动运行管道。它们不仅可以用于重新运行自动化管道，还可以运行只能手动执行的管道。

此外，我们还可以指定管道中的某个步骤需要手动执行。管道的执行将会暂停，直到用户完成该步骤。

让我们来看一下定义仅限手动的管道。

准备就绪

你可以设置仅用于手动运行的管道。这些管道位于它们自己的部分，以custom关键字表示。每个管道都有一个描述其名称和步骤的字符串，显示在 Bitbucket UI 中。以下代码片段描述了两个手动管道和一个自动分支管道：

pipelines:
  custom: # Pipelines that are triggered manually
    manual-sonar: # The name that is displayed in the list in the Bitbucket Cloud GUI
      - step:
          script:
            - echo "triggering for Sonar!"
    deployment-to-prod: # Another display name
      - step:
          script:
            - echo "triggering for manual deployments to prod!"
  branches:  # Pipelines that run automatically on a commit to a branch
    staging:
      - step:
          script:
            - echo "Auto execute for push to staging branch."

手动管道也可以包含在运行时设置或更新的变量。可以使用variables关键字描述变量，并可以使用以下属性进行描述。

• name：变量的名称（这是必需的）

• default：变量的默认值

• allowed-values：允许的值列表

• description：变量的用途和设置的总结

以下代码片段展示了一个带有变量的手动管道：

pipelines:
  custom: # Pipelines that are triggered manually
    us-build: # The name that is displayed in the list in the Bitbucket Cloud GUI
      - variables:
          - name: IAMRole
            default: "admin"          # optionally provide a default variable value
            description: "AWS user role"
          - name: AWSRegion
            default: "us-east-1"
            allowed-values:           # optionally restrict variable values
              - "us-east-1"
              - "us-west-2"
      - step:
          script:
            - echo "$IAMRole manually triggered for a build for $AWSRegion"

我们现在已经定义了可以手动运行的管道。接下来，我们将检查如何运行这些管道以及通常自动运行的管道。

如何操作…

手动执行管道是在 Bitbucket 图形界面（GUI）中完成的。在仓库视图中，你可以在三个位置触发管道运行。我们来看一下这些选项。

从管道视图运行

运行以下步骤以手动执行管道视图中的管道：

1. 在仓库侧边栏中，选择管道选项。

图 6.1 – 选择管道视图

1. 在管道界面中，点击运行 管道按钮。

图 6.2 – 点击运行管道按钮

1. 在弹出的窗口中，选择要运行的分支和管道。点击运行。

图 6.3 – 运行管道

你现在已经从管道视图手动运行了一个管道。

从提交视图运行

你也可以从提交视图手动运行一个管道。在 Bitbucket 仓库中，按照以下步骤操作：

1. 在仓库侧边栏中选择提交。

图 6.4 – 选择提交视图

1. 在提交界面中，通过点击提交哈希值来选择一个提交。

图 6.5 – 选择一个提交

1. 在右侧的详情侧边栏中，选择运行管道。

图 6.6 – 选择运行管道

1. 在窗口中，选择要运行的管道并点击运行。

图 6.7 – 为提交运行管道

你现在已经手动运行了一个针对提交的管道。

从分支视图运行管道

手动运行管道的最后一个位置是分支视图。让我们来看一下如何操作：

1. 在仓库中，从仓库侧边栏选择分支。

图 6.8 – 选择分支视图

1. 在分支页面中，找到感兴趣的分支，选择更多操作图标（...），然后选择为分支运行管道。

图 6.9 – 选择为分支运行管道

1. 在窗口中，选择要运行的管道，并点击运行按钮。

图 6.10 – 为分支运行管道

你现在已经手动运行了一个针对某个分支的管道。

你还可以手动运行管道的个别步骤。让我们在接下来的小节中探讨如何操作。

还有更多内容...

任何不是管道中第一个步骤的步骤都可以指定为手动步骤，需要个体触发该步骤的执行。让我们来看一下如何创建这个配置：

1. 在需要手动运行的步骤上，添加trigger: manual关键字。这告诉 Bitbucket 管道这是一个手动步骤。以下代码片段显示了一个位于两个自动执行步骤之间的手动步骤：

         - step:
             name: 'First Automated Step'
             script:
               - echo "This step is automated"
         - step:
             name: 'Manual Step'
             trigger: manual
             script:
               - echo "This step is manual"
         - step:
             name: 'Second Automated Step'
             script:
               - echo "This step is also automated"
   

2. 在运行管道时，从管道视图中点击进入管道执行。

图 6.11 – 选择管道执行

1. 在执行详情中，点击运行按钮以执行手动步骤。

图 6.12 – 运行手动步骤

我们现在已经在管道中配置并执行了一个手动步骤。

管道执行的另一个理想功能是按周期安排执行。我们将在下一节中探讨如何实现这一点。

定时执行

任何在bitbucket-pipelines.yml文件中定义的管道都可以设置为定期运行。让我们来看看如何进行配置。

如何操作…

在 Bitbucket UI 上进行管道调度，具体操作见以下说明：

1. 在 Bitbucket 仓库中，选择仓库侧边栏中的管道选项。

图 6.13 – 选择管道视图

1. 在管道视图中，点击计划按钮。

图 6.14 – 点击“计划”按钮

1. 要创建新的计划，请点击出现的窗口中的新建计划按钮。

图 6.15 – 新建计划按钮

1. 在创建计划窗口中，选择一个分支，选择一个管道，并选择运行管道的频率。频率可以是每小时、每天、每周或每月。所有时间均以本地时间为准，但将以 UTC 偏移量执行，以避免夏令时配置错误。配置完成后，点击创建按钮。

图 6.16 – 创建新计划

1. 在现有的计划中，你可以点击滑块来禁用该计划。要删除计划，只需将鼠标悬停在该计划上，并点击垃圾桶图标。

图 6.17 – 禁用和删除计划

我们现在已经了解了如何通过计划定期运行流水线。

到目前为止，我们已经看到了从条件执行、手动执行到计划执行的过程。现在我们转向查看我们正在执行的内容，以及如何通过一些增强功能使我们的流水线更强大。第一步是展示如何将 Bitbucket Pipelines 与第三方工具集成。实现这一点的一种方式是使用Pipes。让我们看看如何配置和使用 Pipes 进行集成。

连接到 Bitbucket Pipes

当我们在构建过程中进行持续集成时，我们可能希望进行测试或安全扫描，以确保我们的最终构建质量高且安全。Bitbucket Pipelines 通过使用集成工具来支持测试和安全扫描。Bitbucket Pipelines 与外部工具或环境之间的集成被称为 Bitbucket Pipes。

我们将看到 Bitbucket Pipelines 可用的 Pipes，供与第三方工具和环境进行集成。我们还将看到如何将 Pipes 添加到bitbucket-pipelines.yml文件中，以集成我们的流水线。

如何操作...

Bitbucket 编辑器可以显示可用的 Pipes。然后，这些 Pipes 会被放置在bitbucket-pipelines.yml文件的script部分，如以下指令所示：

1. 正如我们在第五章的 Bitbucket Pipelines 介绍中看到的，当你在 Bitbucket GUI 中编辑bitbucket-pipelines.yml文件时，它会打开一个特殊的编辑器，提供 Pipes、模板、步骤指导和变量等功能。以下截图展示了帮助面板的界面。

图 6.18 – bitbucket-pipelines.yml 编辑器帮助面板

1. 展开添加 Pipes（集成）部分以查看可用的 Pipes。

图 6.19 – 查看 Pipes 的选择

1. 选择探索更多 Pipes时，可以通过关键字搜索或按类别查看，如以下插图所示，该选项位于 Pipes 部分的底部。

图 6.20 – 探索更多 Pipes 按钮

1. 选择探索更多 Pipes将打开探索 Pipes窗口，如以下插图所示。

图 6.21 – 探索 Pipes 窗口

1. 选择一个管道会打开一个管道窗口。该窗口将包含代码片段，供你粘贴到你希望管道运行的步骤的脚本部分，还会显示有关管道的详细信息和其他信息。我们将在接下来的插图中展示这一示例。

图 6.22 – 管道窗口

我们将在本章以及第八章和第九章中看到管道的应用。

管道的另一个功能是变量。我们从第五章的启用 Bitbucket Pipelines中定义变量开始。接下来让我们看看如何在管道中设置变量并使用它们。

定义变量

变量通过允许你存储诸如名称、所需参数以及有时的机密等值，增强了管道的功能。你可以通过两种方式来定义变量，第一种方式我们在第五章中提到过。让我们来详细看看这些方法。

如何操作…

正如我们在第五章中看到的，我们可以通过编辑器为bitbucket-pipelines.yml定义变量。让我们来看一下如何做到这一点：

1. 编辑bitbucket-pipelines.yml时，选择添加 变量选项。

图 6.23 – 展开添加变量

1. 你可以为仓库以及任何已定义的部署环境添加变量。

图 6.24 – 添加变量

1. 要添加变量，给它起个名字，输入其值，然后点击添加。如果需要一个安全的变量来存储密码或机密，请确保勾选已加密。

图 6.25 – 变量已保存

1. 要在bitbucket-pipelines.yml中使用变量，请将变量名添加到script:部分，并在前面加上美元符号（$）。如下代码片段所示：

   - step:
             name: 'Build and Test'
             script:
               - echo "My variable is "$MY_NUMBER
   

我们已经看到如何通过bitbucket-pipelines.yml编辑器添加变量。接下来，让我们看看如何通过仓库设置来添加变量，详细信息请见下一小节。

还有更多……

任何有写入权限的仓库成员都可以创建仓库变量。让我们看看如何通过仓库设置来实现：

1. 在仓库中，从仓库侧边栏选择仓库设置。

图 6.26 – 选择仓库设置

1. 在仓库设置侧边栏的PIPELINES部分，选择仓库变量。

图 6.27 – 选择仓库变量

1. 要添加变量，给它起个名字，输入其值，然后点击添加。如果需要一个安全的变量来存储密码或机密，请确保勾选已加密。

图 6.28 – 添加仓库变量

1. 与上一部分一样，要在 bitbucket-pipelines.yml 中使用变量，将变量名添加到 script: 部分，并在其后附加美元符号 ($) 字符。以下代码片段展示了这一点：

   - step:
             name: 'Build and Test'
             script:
               - echo "My variable is "$MY_NUMBER
   

我们已经看到如何在 仓库设置 中添加变量。

另请参阅

以下链接提供了更多关于变量的信息，包括预定义的 Bitbucket 变量：

• support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/

我们可以指定在执行管道时使用哪些运行器。让我们现在来探索这个。

为管道定义运行器

在 第五章中，我们了解了如何定义自托管的运行器。Bitbucket Pipelines 允许使用自托管的运行器，不仅能确保我们使用正确的平台进行构建，而且通过指定我们自己的资源，能够避免 Bitbucket Cloud 的构建时间限制。

现在我们已经定义了运行器，让我们看看如何在 bitbucket-pipelines.yml 中调用它们。

如何操作...

你的自托管运行器可以在 bitbucket-pipelines.yml 文件中按步骤定义。让我们看看如何做到这一点：

1. 对于给定的步骤，通过添加 runs-on 关键字并跟随所有适用的标签来定义该步骤使用的运行器。以下代码片段展示了这样的应用：

   pipelines:
     custom:
       customPipelineWithRunnerStep:
         - step:
             name: First Step
             runs-on:
               - 'self.hosted'
               - 'my.label'
             script:
               - echo "This step will run on a self hosted runner that also has the my.label label.";
   

2. 当在 runs-on 部分添加 windows 标签时，将使用 Windows 特定的运行器：

         - step:
             name: First Step
             runs-on:
               - 'self.hosted'
               - 'windows'
   

3. 当在 runs-on 部分添加 macos 标签时，将使用 Mac 特定的运行器：

         - step:
             name: First Step
             runs-on:
               - 'self.hosted'
               - 'macos'
   

4. 当在 runs-on 部分添加 linux.shell 标签时，将使用 Linux shell 运行器：

         - step:
             name: First Step
             runs-on:
               - 'self.hosted'
               - 'linux.shell'
   

5. 当在 runs-on 部分添加 linux.arm64 标签时，将使用 Linux Docker ARM 运行器：

         - step:
             name: First Step
             runs-on:
               - 'self.hosted'
               - 'linux.arm64'
   

6. 如果你没有指定平台标签，Bitbucket Pipelines 将假定该步骤应由 Linux Docker 运行器执行。

7. 如果所有匹配的运行器都在忙碌，你的步骤可能会等待直到有一个可用。如果你的仓库中的运行器与步骤中的任何标签不匹配，步骤将失败。

我们现在准备探索在管道中作为持续集成的一部分进行测试的实际应用。现在让我们看一个测试示例。

在 Bitbucket Pipelines 中进行测试步骤

在持续集成的管道中，一个关键步骤通常是在构建后进行的。构建后立即进行测试，可以发现并解决缺陷，从而保证代码库的更高质量。

本教程中的测试步骤使用了一类被称为 静态分析 的测试。在静态分析中，构建中的文件将被扫描，以查看是否包含逻辑错误、安全漏洞或其他问题。

Linting 是另一种扫描技术，通过评估代码库的语法和结构来执行测试。它还可以确定被评估的代码库是否符合特定的编码标准。

我们将探讨从 Bitbucket Pipelines 调用 linting 和扫描的不同方法。

如何操作…

根据语言的不同，linting 工具可能是开发该语言的工具套件的一部分。让我们看看 Bitbucket Pipelines 中是如何运作的：

1. 作为语言开发平台一部分的测试可以在测试步骤的 script 部分中调用。通过在 script 部分设置步骤来执行捆绑的测试。以下代码片段展示了用于 Node.js 应用程序的构建和测试步骤，其中 image 部分表示作为构建环境使用的 Docker 镜像——我们在 第九章 中对此进行了说明：

   image: node:10.15.0
   pipelines:
     default:
       - step:
           script:
             - npm install
             - npm test
   

2. 我们可以通过添加 linting 应用程序来扩展测试。以下代码片段包含了 ESLint 的安装和执行，ESLint 是我们 Node.js 环境中常用的 JavaScript linting 应用程序：

   image: node:10.15.0
   pipelines:
     default:
       - step:
           name: ESLint
           script:
             - npm install eslint --save-dev
             - eslint --init
       - step:
           name: execute
           script:
             - npm install
             - npm run lint
             - npm test
   

我们现在已经看到了当编程语言的开发环境包含测试应用程序时如何运行测试。让我们在下一个小节中看看如何将第三方应用程序集成到我们的 Bitbucket Pipeline 中。

还有更多…

一个常用的测试应用程序是来自 SonarSource 的 SonarCloud。SonarCloud 提供了一系列测试，用于衡量代码库的安全性、可靠性和可维护性。配置 SonarCloud 与 Bitbucket Cloud 后，可以按照以下方式在 Bitbucket Pipelines 中设置测试执行：

1. SonarCloud 扫描利用管道从 Bitbucket Pipelines 运行 SonarCloud 代码分析器。以下代码片段展示了在测试步骤的 script 部分中调用管道。这段示例包括了管道的所有可选变量。请注意，SONAR_TOKEN 使用的是 Bitbucket 安全变量：

   - step:
       name: SonarCloud
       script:
          - pipe: sonarsource/sonarcloud-scan:2.0.0
               variables:
                  SONAR_TOKEN: $SONAR_TOKEN
                  EXTRA_ARGS: -Dsonar.projectDescription=\"Project with sonarcloud-scan pipe\" -Dsonar.eslint.reportPaths=\"report.json\"
                  SONAR_SCANNER_OPTS: -Xmx512m
                  DEBUG: "true"
   

2. 除了 SonarCloud 扫描之外，Bitbucket Pipelines 还可以包括对 SonarCloud Quality Gate 的调用，以在部署或发布之前对定义的质量门进行检查。此调用也被建立为一个管道，可以添加到 script 部分。以下代码片段展示了带有可选变量的管道：

   - pipe: sonarsource/sonarcloud-quality-gate:0.1.6
     variables:
        SONAR_TOKEN: $SONAR_TOKEN
       SONAR_QUALITY_GATE_TIMEOUT: 180  # 3 minutes
   

你现在已经看到了 Bitbucket Pipelines 如何通过管道与 SonarCloud 分析器连接。

另请参见

该链接包含将 Bitbucket 工作区连接到 SonarCloud 项目的所需步骤：docs.sonarsource.com/sonarcloud/getting-started/bitbucket-cloud/。

DevSecOps 的一个核心原则是频繁运行安全扫描和测试。最理想的是，这应该是持续集成的一部分。让我们看一个在 Bitbucket Pipelines 中包含安全扫描的示例。

Bitbucket Pipelines 中的安全步骤

截至本文写作时，Snyk 是唯一一个能够深入集成 Bitbucket Cloud 的安全提供商。将 Snyk 作为安全提供商，可以将额外的安全扫描添加到开发流程中的仓库步骤中。该流程的一部分包括在 Bitbucket Pipelines 中运行安全扫描。让我们看看如何实现这一点。

如何操作…

Snyk 使用管道与 bitbucket-pipelines.yml 中定义的流水线集成。我们来看看如何设置：

1. 将 Snyk 管道添加到流水线测试步骤的 script 部分。所需的变量包括 Snyk token、使用的语言（node、ruby、composer、dotnet 或 docker），如果语言设置为 docker，还需要指定镜像名称。以下代码片段展示了扫描 Node.js 应用程序的用法：

   script:
     - npm install
     - npm test
     - pipe: snyk/snyk-scan:1.0.1
       variables:
         SNYK_TOKEN: $SNYK_TOKEN
         LANGUAGE: «node»
   

2. 你还可以使用 Snyk CLI 通过 snyk test 运行扫描。可以通过 npm 安装 Snyk CLI。以下代码片段演示了安装过程：

   script:
     - mvn install
     - npm install -g snyk # binary download also available
     - snyk test --all-projects
   

你现在已经成功设置了 Snyk，使其作为流水线的一部分运行安全扫描。

另请参见

以下链接详细说明了如何将 Snyk 设置为 Bitbucket Cloud 的安全提供商：

• support.atlassian.com/bitbucket-cloud/docs/add-and-configure-security-with-snyk/

在某些测试中，Bitbucket 可以自动检测结果输出并显示。我们在最后一个教程中探讨了这一点。

报告测试结果

输出为 JUnit 和 Maven Surefire XML 格式的测试结果将会被流水线自动检测到。Bitbucket Pipelines 随后会在 Tests 标签中显示任何失败的测试结果。成功的执行结果可以在 Build 标签的日志视图中查看。我们来看看如何进行设置。

准备工作

在设置测试报告时，请确保测试结果生成在以下位置之一：

• ./**/``surefire-reports/**/*.xml

• ./**/``failsafe-reports/**/*.xml

• ./**/``test-results/**/*.xml

• ./**/``test-reports/**/*.xml

• ./**/``TestResults/**/*.xml

现在，让我们看看如何在流水线中配置测试结果。

如何操作…

根据语言的不同，生成测试结果的方法各有不同。我们来看看每种方法：

1. 如果你在 Maven 构建任务中使用 Maven Surefire 插件，则无需进行特殊配置。

2. 如果你使用 PHP 并通过 PHPUnit 进行测试，应该包括 --log-junit 参数以生成日志输出。以下代码片段演示了正确的命令设置：

   image: php:7.1.1
   pipelines:
     default:
       - step:
           script:
             - apt-get update && apt-get install -y unzip
             - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
             - composer require phpunit/phpunit
             - vendor/bin/phpunit --log-junit ./test-reports/junit.xml
   

3. 如果你使用 .NET 开发，可以使用 JUnitTestLogger 以 JUnit 格式创建输出。以下代码片段演示了设置方法：

   image: mcr.microsoft.com/dotnet/sdk
   pipelines:
     default:
       - step:
           script:
             - dotnet add package JUnitTestLogger --version 1.1.0
             - dotnet test --logger "junit"
   

4. .NET 开发也可以使用 trx2junit 工具将 Visual Studio 测试结果文件（.trx）转换为 JUnit 格式（.xml）。以下代码片段演示了这一过程：

   image: mcr.microsoft.com/dotnet/sdk
   pipelines:
     default:
       - step:
           script:
             - dotnet tool install -g trx2junit
             - dotnet test --logger 'trx;LogFileName=log.trx'
           after-script:
             - export PATH="$PATH:/root/.dotnet/tools"
             - trx2junit ./TestResults/*.trx
   

你现在已经了解了如何准备测试结果，以便它们能自动显示在日志中。

第七章：利用测试用例管理和安全工具进行 DevSecOps

在本章中，我们将继续探索安全性，这是从 DevOps 转向DevSecOps视角所必需的一个组件。这要求将额外的工具集成到 DevOps 工具链中，而Open DevOps使这一过程更加简便。

在本章中，我们将查看来自 Atlassian Marketplace 的应用，这些应用可以记录和执行测试，并供 Jira 参考。

我们还将学习如何将 Jira 与流行的安全工具（如 Snyk 和 SonarQube）连接。我们将学习如何在 Jira 中跟踪安全工具发现的漏洞的修复情况。最后，我们将了解 Jira 中用于安全测试的容器，并从漏洞创建问题。

完成本章后，您应该能够很好地理解如何将测试组件（无论是与 Jira 相关还是与软件相关）纳入 Open DevOps 工具链中。

本章包含以下教程：

• 将测试用例管理添加到 Jira

• 将 Jira 连接到安全工具

• 管理漏洞

技术要求

要完成本章，您需要以下内容：

• Jira

• 一个 Snyk 账户（snyk.io/）

将测试用例管理添加到 Jira

Jira 的功能可以通过利用流行的市场应用（如 Xray 或 Zephyr）扩展到测试用例管理中。

测试用例管理应用允许 Jira 用户自动执行多种类型的软件测试，包括以下内容：

• 使用测试

• 集成测试

• 功能测试

• 验收测试

• 性能测试

在本示例中，我们将把 Xray 测试用例管理应用添加到 Jira 中。

准备工作

如前几章所示，市场应用可以由产品管理员安装。您需要是 Jira 产品管理员才能执行此教程。

什么是 Xray？

Xray for Jira 是一款全面的测试用例管理工具，能够与 Jira 无缝集成。Xray 扩展了 Jira 的功能，使团队可以直接在 Jira 环境中管理整个测试生命周期。

如何操作……

Xray 是一款付费应用，为用户提供 30 天的免费试用期。请按照以下说明将 Xray 测试用例管理功能集成到 Jira 中：

1. 作为站点或产品管理员，点击齿轮图标中的应用菜单项。

图 7.1 – 查找新应用

1. 这将带你到 xray 并按 Enter。所有相关的应用都会展示出来。选择Jira 的 Xray 测试管理应用。

图 7.2 – 搜索 Xray 应用

1. 选择免费试用以开始安装过程，并启动 30 天的试用期。

图 7.3 – 获取 Xray 应用

1. 添加到 Jira的弹出窗口将显示出来。选择开始免费试用按钮以继续安装过程。

图 7.4 – 添加 Xray 应用程序

1. 一旦应用程序安装并准备就绪，会弹出一个窗口，允许你配置应用程序。选择配置选项。

图 7.5 – 配置 Xray 应用程序

1. 显示XRAY配置页面。查看选项并根据需要进行任何调整。在这个示例中，我们将保留所有默认值。

图 7.6 – Xray 配置页面

1. 接下来，我们需要为 Jira 项目配置 Xray 测试用例问题类型。为此，从应用下拉菜单中选择Xray。

图 7.7 – 从应用下拉菜单中选择 Xray

1. 显示开始使用 Xray页面。要使用测试用例问题类型配置 Jira 项目，请从左侧菜单选项或项目配置和组织面板中选择配置项目。

图 7.8 – 开始使用 Xray

1. 在配置现有项目时，Xray 问题类型将被添加到指定的项目中。从下拉菜单中选择要配置的项目，然后点击配置按钮。

图 7.9 – 选择要配置的项目与 Xray

1. 显示 Xray 项目摘要页面。测试用例问题类型以红色X显示，表示它们当前不在项目中。在项目中的 Xray 问题类型文本框中，选择添加 Xray 问题 类型选项。

图 7.10 – 将 Xray 问题类型添加到项目

1. 会弹出一个对话框，要求你确认是否将问题类型添加到项目的问题类型方案中。如果问题类型方案是共享的，新的问题类型将被添加到与该方案关联的所有其他项目中。选择是以继续；否则，你需要在添加测试用例问题类型之前，将项目与一个新的独立问题类型方案关联。

图 7.11 – 确认添加 Xray 问题类型

现在，Xray 问题类型已显示绿色勾选标记，表示它们已被添加到项目中，并且现在可以使用。

图 7.12 – 添加到项目的 Xray 问题类型

1. 为了验证前面的步骤是否正确完成，在Jira菜单的顶部选择创建按钮。

图 7.13 – 在 Jira 中创建问题

1. 会出现一个新的创建问题窗口。在问题类型下拉菜单中，你将看到现在可用的测试问题类型。继续填写任何必填字段，以创建一个测试问题类型的新问题。

图 7.14 – 创建一个测试问题类型

1. 创建后，打开新问题。你现在会看到在描述字段下方有一个测试详情部分面板。测试详情部分允许你添加测试步骤、前提条件、测试集和测试计划，并管理测试运行。

图 7.15 – 可添加至问题中的 Xray 测试详情

如需进一步了解如何使用 Xray 测试用例功能，请参阅以下文档：docs.getxray.app/display/XRAYCLOUD/About+Xray

在本教程中，我们已成功安装并配置了 Jira 的 Xray 测试用例管理应用。用户现在可以创建测试用例问题类型，并定义这些测试用例的测试步骤和预期结果。

连接 Jira 与安全工具

现在我们将介绍 Open DevOps 工具链中的 DevSecOps 概念。DevSecOps 将安全实践（如漏洞扫描）引入 CI/CD 流水线。通过将 Jira 与流行的外部安全工具（如 Snyk 和 SonarQube）连接，我们可以实现 DevSecOps。

本教程内容是将 Snyk 安全工具连接到 Jira。

准备工作

本教程内容是通过 Snyk 安全应用将 Jira 实例与 Snyk 账户连接。在此操作正常进行的前提是，你已拥有现有的 Snyk 账户（snyk.io/），将 Snyk 账户连接到源代码控制库（即 Bitbucket 或 GitHub），并且正在积极扫描源代码。

你还必须是 Jira 产品管理员才能执行此操作。

什么是 Snyk？

Snyk 是一款应用安全扫描工具，专门用于识别和修复源代码中的漏洞。将你的 Jira 和 Snyk 账户连接，可以让你直接在 Jira 中管理代码漏洞。

操作步骤…

我们将通过以下步骤连接 Jira 与 Snyk：

1. 作为站点或产品管理员，我们需要为相应的 Jira 项目启用安全功能。为此，请前往项目设置，然后选择功能菜单选项。这将带你到功能页面。

图 7.16 – 项目设置 | 功能

1. 向下滚动页面，直到看到开发面板，然后通过将开关切换为绿色来启用安全性部分。

图 7.17 – 启用安全性

1. 现在我们已经为项目启用了安全，前往应用市场并搜索 Snyk 应用。选择 Snyk Security in Jira Cloud 应用。

图 7.18 – 在 Jira Cloud 应用中搜索 Snyk 安全

1. 选择 获取应用 以开始安装过程。

图 7.19 – 获取 Snyk 安全应用

1. 添加到 Jira 弹出窗口将出现。选择 立即获取 按钮以继续安装过程。

图 7.20 – 选择立即获取 Snyk 安全

1. 一旦应用安装并准备就绪，将显示一个窗口，允许您配置应用。选择 开始 使用 选项。

图 7.21 – 在 Jira 中开始使用 Snyk 安全

1. Snyk 配置页面已显示。在这里，我们需要连接一个新的或现有的 Snyk 账户。对于此操作，我们假设您已经有一个 Snyk 账户，所以请选择 登录到您的 账户 按钮。

图 7.22 – Snyk 配置

1. 一个新的浏览器标签页将打开，并显示一条消息，要求您授予 Jira 访问您的 Snyk 账户的权限。选择 授予 应用访问权限。

图 7.23 – 授予 Jira 访问 Snyk 权限

1. 新的浏览器窗口将显示一条消息，表明您的 Snyk 账户已成功连接到 Jira。关闭此浏览器窗口并返回到开始连接过程的前一个浏览器标签页。

图 7.24 – Snyk 访问成功

1. 之前的浏览器现在会显示一条消息，要求您刷新更新后的 Snyk 配置。点击 刷新页面 链接。

图 7.25 – Snyk 配置刷新

1. Snyk 配置页面现在显示您的连接的 Snyk 组织。要验证连接，请选择 Snyk 组织旁边的三个点。

图 7.26 – Snyk 配置

1. 在查看 Snyk 组织和项目的菜单选项中，选择 在 Snyk 中打开 选项。

图 7.27 – 在 Snyk 中打开查看

1. 一个新的浏览器窗口将打开，并显示您的 Snyk 仪表盘。点击左侧的 项目 菜单选项，以显示您的 Snyk 组织中包含的代码库。这确认了您的 Jira 到 Snyk 集成。

图 7.28 – Snyk 项目

现在我们已将 Snyk 和 Jira 连接起来，可以查看如何在 Jira 中管理漏洞。

管理漏洞

一旦将适当的 Jira 项目与对应的 Snyk 项目连接，你将能够查看和管理由于定期或手动代码扫描所产生的漏洞。可以从已识别的漏洞中创建 Jira 问题，以便跟踪和解决这些漏洞。

准备工作

为了执行此操作，你需要以下内容：

• Jira

• Jira 管理权限

• 一个现有的 Snyk 账户 (snyk.io/)

如何操作...

在上一个操作中，我们安装并配置了 Snyk for Jira 应用，将我们的 Snyk 账户与 Jira 连接。现在，我们需要将适当的 Snyk 项目添加到我们的 Jira 项目中，以管理任何漏洞。让我们按以下步骤进行：

1. 要将 Snyk 安全容器添加到 Jira 项目中，我们需要进入 项目设置 | 工具链。

图 7.29 – Jira 工具链项目设置

1. 然后显示 工具链 配置页面。由于我们安装了 Snyk for Jira 应用，因此可以看到 Snyk 安全在 Jira 面板。选择 添加 安全容器。

图 7.30 – Jira 工具链配置页面

1. 显示一个 添加安全容器 弹出窗口。点击下拉菜单查看 Snyk 中的可用项目。选择适当的 Snyk 项目，然后点击 添加 按钮。

图 7.31 – 添加安全容器

1. 工具链 窗口中的 Snyk 安全在 Jira 框现在显示已添加的安全容器。

图 7.32 – 已添加到项目的 Snyk 安全容器

1. 现在我们已将 Snyk 安全容器添加到项目中，可以查看扫描到的任何漏洞的容器。返回到 项目 以返回项目摘要页面。在那里，选择 开发 部分的 安全 菜单选项。

图 7.33 – 安全菜单选项

1. 安全 页面将显示已附加的安全容器及该容器中发生的任何漏洞。在此示例中，我们可以看到当前扫描代码中存在一个 中等 代码注入漏洞。

图 7.34 – 安全容器页面

1. 如果我们切换到 Snyk 视图查看该漏洞，我们可以看到相同的 代码注入 漏洞的详细信息。

图 7.35 – Snyk 漏洞视图

1. 从 Jira 漏洞页面视图中，我们可以通过点击创建 问题选项来创建一个问题以跟踪和解决漏洞。

图 7.36 – 从漏洞创建 Jira 问题

1. 创建问题窗口显示，描述和摘要字段已预填充有关漏洞的信息。选择问题类型（即Bug），并添加任何其他必要的信息，然后点击创建按钮。

图 7.37 – 从漏洞创建问题

1. 一旦 Jira 问题被创建，你将在漏洞的问题栏中看到 Jira 问题关键字。

图 7.38 – 与漏洞关联的问题

1. 点击 Jira 问题关键字以调出完整的问题视图。

图 7.39 – 关联问题的完整视图

在这个示例中，我们能够看到将代码漏洞应用程序与 Jira 集成的真正好处。我们能够看到具体的漏洞，并简单地创建一个 Jira 问题来跟踪和修复漏洞。

第八章：使用 Bitbucket Pipelines 部署

在了解 Bitbucket Pipelines 的过程中，我们从 bitbucket-pipelines.yml 文件的概念开始。

我们现在处于部署阶段，需要将之前在 Bitbucket Pipelines 中创建的构建安装到我们的某个环境中，从测试环境到预发布环境，最后到生产环境。如果我们扩展 Bitbucket Pipelines 以实现自动部署，我们必须考虑 持续部署。

本章中，我们将查看如何在 bitbucket-``pipelines``.yml 中进行必要的添加以执行持续部署。为此，我们将涵盖以下配方：

• 配置部署

• 将工件推送到 Bitbucket 仓库

• 将工件推送到工件仓库工具

• 部署工件到 Bitbucket 下载

• 使用 Secure Copy Protocol (SCP) 部署工件

• 将工件部署到 AWS S3 存储桶

• 将工件部署到 AWS Lambda

• 部署工件到 Google Cloud

• 部署工件到 Microsoft Azure

• 在部署阶段使用 Ansible

• 在部署阶段使用 Terraform

技术要求

因为我们仍在使用 Bitbucket Pipelines，所以需要订阅 Bitbucket Cloud。对于将工件最终放入代码库或 Bitbucket 下载的配方，仍然需要此订阅。

将工件部署到 AWS、Google Cloud 和 Microsoft Azure 等云环境，需要在本章的配方中使用的服务拥有权限的账户。

本章节的示例代码可以在本书 GitHub 仓库的Chapter8文件夹中找到：github.com/PacktPublishing/Atlassian-DevOps-Toolchain-Cookbook/tree/main/Chapter8

现在，让我们来探索如何为部署准备构建。

配置部署

尽管 Bitbucket Pipelines 可以部署到多个不同的平台，但部署的特点是相同的。这在你部署到测试环境时非常有利，你可能需要定义一些运行时测试或包测试，而在生产环境中，测试已经完成，可以发布新的功能给最终用户。

有了这个考虑，我们来看看部署的共同点是什么，以及如何统一定义它们。之后，我们将学习如何为典型 DevSecOps 流程中的不同环境配置部署。

准备工作

在设置管道之前，我们需要定义部署环境。你可以使用默认的环境，它们有以下预定义设置：

• 测试环境

• Staging（预发布环境）

• 生产环境

你还可以更改环境的名称或为部署配置特定于环境的变量。要设置环境配置，请执行以下步骤：

1. 在 Bitbucket 中，进入感兴趣的代码库并选择 Repository settings（代码库设置）。

图 8.1 – 选择仓库设置

1. 在流水线部分，选择部署选项。

图 8.2 – 选择部署

1. 默认环境列表将显示，分为测试、预发布和生产。

图 8.3 – 部署环境

1. 要更改现有环境，点击代表该环境的条带。它将展开，显示您可以用来更改名称的选项以及一个用于环境特定变量的部分。

图 8.4 – 环境的配置选项

要更改名称，在环境名称：字段中覆盖名称。要添加变量，请填写名称和值字段。如果变量包含密码或密钥等秘密信息，请确保选中已加密复选框。最后点击添加按钮。

1. 要添加一个新环境，进入定义环境类型（测试、预发布或生产）的部分，并点击添加 环境按钮。

2. 填写新环境的名称，并选择预发布 环境复选框。

图 8.5 – 添加一个环境

在 Bitbucket 的免费计划中，您可以定义 10 个环境。在 Bitbucket 的高级版本中，这个限制增加到 100。Bitbucket 的高级版本允许您限制哪些分支可以部署到该环境，并且可以设置只有管理员才能在该环境上执行任何部署。

现在我们已经配置好了环境，是时候配置部署了。

如何做...

要定义一个部署，我们必须在 bitbucket-pipelines.yml 文件中引入新的关键字和部分。我们将在流水线的阶段或步骤中应用这些关键字和部分。

一旦完成此配置，我们可以根据接收来自下级分支合并的分支来定义单独的部署。这使我们能够不断地进行部署和测试，直到最终的拉取请求提交到主分支，在生产环境中可能会进行部署。

让我们看看如何执行这些部署。

在 bitbucket-pipelines.yml 中配置部署

部署指令在 bitbucket-pipelines.yml 文件的阶段或步骤中通过 deployment: 关键字标识，并指定部署步骤或步骤的目标环境。让我们学习如何使用 deployment: 关键字：

1. deployment: 关键字在步骤中用于标识正在部署的环境。以下代码片段中展示了一个示例：

   pipelines:
     default:
       - step:
           name: Deploy to staging
           deployment: staging
           script:
             - python deploy.py staging_1
   

   你可以为部署定义多个步骤，每个步骤都会标明环境。然而，Bitbucket 要求环境类型按以下顺序排列：

   1. 测试环境。

   2. 阶段环境

   3. 生产环境

2. 如果部署需要多个步骤，可以在阶段定义中使用deployment:关键字来标识目标环境。以下代码片段展示了这一示例：

   pipelines:
      default:
         - stage:
               name: Deploy to Production
               deployment: production
               steps:
                   - step:
                      name: Basic deploy first step
                      script:
                            - sh ./deploy1.sh
                   - step:
                       name: Basic deploy second step
                       script:
                          - sh ./deploy2.sh
   

3. 如果你希望部署步骤被手动触发，请在部署步骤中添加trigger: manual关键字。以下代码片段展示了这一操作：

   - step:
         name: Deploy to staging
         deployment: staging
         trigger: manual
         script:
            - python stage_deploy.py staging
   

一旦我们在bitbucket-pipelines.yml文件中定义了部署步骤或阶段，我们就可以在 Bitbucket 中监控部署的进度和结果。我们来看看如何操作。

监控部署

一旦你执行了部署，你可以在部署仪表板中跟踪其进度或手动执行部署。我们来看看部署仪表板的功能：

1. 正如我们在前面的配方中看到的，要访问部署仪表板，请在仓库级别的侧边栏中选择部署。

2. 部署仪表板将出现在侧边栏的右侧。它被划分为在bitbucket-pipelines.yml文件中定义的环境。在该环境内，将显示一个卡片，展示该环境中最后一次成功的部署。

图 8.6 – 部署仪表板

1. 点击环境中的卡片，查看该环境的部署详情。详情包括导致bitbucket-pipelines.yml执行的提交，现有版本与提交之间的差异说明，以及推送到关联环境的内容，包括部署历史。如果 Jira 和 Bitbucket 已连接，正如我们在第一章的连接 Bitbucket配方中讨论的，你还将看到与提交相关的 Jira 问题。以下截图展示了部署到测试环境。

图 8.7 – 部署到测试环境

1. 如果部署被定义为手动触发，你将在最后一次成功部署到较低环境的卡片上看到一个提升按钮。点击提升按钮即可执行部署到更高的环境。

图 8.8 – 将手动部署提升到生产环境

1. 如果部署失败，你可以从部署仪表板重新部署上次成功的部署。重新部署的能力要求满足以下条件：

   • 管道中的初始部署步骤已成功执行

   • 部署权限设置为允许重新部署该步骤（请注意，这仅在 Bitbucket 的高级计划中提供）。

   • 用于部署的产物不能过期。

2. 一旦部署到特定环境被启动，来自其他 Pipelines 的任何后续部署都会被暂停，这得益于并发控制，它将每个环境的部署限制为一次。原始部署完成后，您可以对暂停的部署进行以下操作：

   • 从头开始重新运行 Pipeline

   • 从暂停处恢复 Pipeline

现在我们了解了部署的机制，如果与特定分支相关联的拉取请求成功，我们就可以允许部署到特定环境。让我们看看如何做到这一点。

从拉取请求或分支进行部署

如你从第六章的条件执行 Pipelines的配方中所记得的，你可以设置你的 Pipelines，根据接收新提交的分支或是否有拉取请求被创建，执行不同的指令。让我们学习如何建立这些不同的条件：

1. 分支 Pipeline 指定在特定分支上发生推送时需要执行的操作。您可以使用 branches: 关键字来描述分支 Pipeline 上发生的操作。这些操作会在分支名称下分组。以下代码片段详细说明了使用 default: 关键字时，针对其他分支的部署操作，以及为暂存分支设定的独立操作：

   pipelines:
      default:
        - step:
            script:
              - echo "We do this on all branches except staging"
      branches:
        staging:
          - step:
              deployment: staging
              script:
                - echo "Done on the staging branch"
                - python deploy.py
   

2. 拉取请求 Pipeline 允许您指定在特定分支上创建拉取请求时执行的操作。这些操作在 pull-requests: 关键字下的分支中定义。让我们来看一下当拉取请求发生在暂存分支时完成的操作：

   pipelines:
      pull-requests:
        staging/*:
           - step:
               deployment: staging
               script:
                 - echo "Test and deploy pre-merge"
                 - python deploy.py
   

通过这些内容，我们已经学会了如何在功能分支发生更改时轻松进行测试和部署。当从暂存分支到生产分支的拉取请求被创建时，自动部署到生产环境是可能的。

现在我们已经了解了如何配置 Bitbucket Pipelines 进行部署，接下来我们将查看根据目标执行特定部署的示例。首先，我们将学习如何将部署内容推送到 Bitbucket git 仓库本身。

将构建产物推送到 Bitbucket 仓库

部署过程的一部分可能是将构建产物放置到正确的仓库中。最方便的存储构建产物的仓库可能就是 Bitbucket 本身。通常不推荐这么做，因为构建产物通常会占用大量存储空间，并可能导致底层 git 工具的性能问题。不过，如果没有其他替代方案，我们提供了这个方法。

让我们学习如何将构建产物推送回 Bitbucket 仓库，作为部署的一部分。

准备工作

尽管推荐将内容推送到 git 仓库的方式是使用 HTTP，但有时唯一可行的方式是使用 SSH。为了做到这一点，你需要设置你的凭据。如果你在仓库上启用了分支权限，或者想为这些操作设置一个自动化账户，那么这种情况是适用的。一个重要的考虑因素是，配置这些账户后，会取消对它们能访问的限制。

让我们学习如何创建具有不同认证方式的账户。

使用 OAuth 进行认证

你可以使用 OAuth 作为访问 git 仓库的认证方式。这涉及到创建一个账户，并通过分支权限授予该账户对主分支或 master 分支的写入权限。让我们学习如何使用 OAuth 设置一个账户：

1. 在 Bitbucket 的工作区页面，点击设置齿轮图标，选择工作区设置。

图 8.9 – 选择工作区设置

1. 在工作区设置的侧边栏中，找到应用程序和功能部分，选择OAuth 消费者。

图 8.10 – 选择 OAuth 消费者

1. 在OAuth 消费者页面，点击添加 消费者按钮：

图 8.11 – 添加消费者

1. 在后续页面中，填写以下详细信息：

   • 名称

   • 设置回调 URL为 bitbucket.org

)

+   确保勾选**这是一个私人消费者**

1. 对于权限，确保在仓库下勾选了读取和写入权限。点击保存按钮保存 OAuth 消费者：

2. 返回到消费者页面，找到你创建的新消费者。将密钥和密钥保存在安全的管道变量中。将 CLIENT_ID 用作密钥，CLIENT_SECRET 用作密钥：

图 8.12 – OAuth 消费者密钥和密钥

1. 在 bitbucket-pipelines.yml 文件的 script 部分添加以下代码片段，在 git 命令之前进行更改并提交到 git 仓库。我们假设你的运行器已经安装了 curl 和 jq 工具：

   - >
     export access_token=$(curl -s -X POST -u "${CLIENT_ID}:${CLIENT_SECRET}" \
       https://bitbucket.org/site/oauth2/access_token \
       -d grant_type=client_credentials -d scopes="repository"| jq --raw-output '.access_token')
   # Configure git to use the oauth token.
   - git remote set-url origin https://x-token-auth:${access_token}@bitbucket.org/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}
   

这样，你就配置了一个 OAuth 消费者，并允许它从 Bitbucket Pipelines 进行 git 提交。

我们也可以使用 Bitbucket UI 设置 SSH 密钥。让我们看看如何操作。

为 Bitbucket Pipelines 创建 SSH 密钥对

对于给定的仓库，你可以创建一个 SSH 密钥对，并将公钥保存在 Bitbucket 中，以便可以使用 SSH 将其部署回 git 仓库。让我们看看这是如何实现的：

1. 在仓库页面，选择侧边栏中的仓库设置：

2. 在仓库设置侧边栏的Pipelines部分，选择SSH 密钥：

图 8.13 – 选择 SSH 密钥

1. 在SSH 密钥页面，选择生成密钥：

图 8.14 – 生成密钥

1. 复制生成的公钥：

图 8.15 – 复制公钥

1. 此时，您需要将公钥添加到您的个人 Bitbucket 设置中。首先，选择设置图标，然后点击个人 Bitbucket 设置：

2. 在个人设置侧边栏的安全性部分，选择SSH 密钥：

图 8.16 – 选择 SSH 密钥

1. 在SSH 密钥页面上选择添加密钥：

图 8.17 – 添加密钥

1. 在添加 SSH 密钥弹窗中，粘贴公钥并选择添加密钥：

图 8.18 – 粘贴并添加公钥

1. 以下代码行需要添加到 bitbucket-pipelines.yml 文件的 script 部分，在 git 命令之前，以便您可以将更改保存并提交回 git 仓库。此行配置 git 使用 SSH。BITBUCKET_GIT_SSH_ORIGIN 是一个默认的环境变量：

   git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
   

完成这些配置后，您已经设置了 SSH 密钥，在将提交推送回 git 仓库时进行身份验证。

另一种身份验证方法是创建一个应用密码，并将其作为安全变量传递。让我们来看看如何操作。

创建应用密码

应用密码是您可以在 Bitbucket 中安全使用的个人秘密，用于自动化功能。让我们看看如何创建一个应用密码：

1. 选择设置图标并选择个人 Bitbucket 设置。

2. 在个人设置侧边栏的访问管理部分，选择应用密码。

3. 在应用密码页面上，选择创建 应用密码：

图 8.19 – 创建应用密码

1. 在添加应用密码页面上，为应用密码命名，并确保在仓库部分选中读取和写入权限。完成后，点击创建：

2. 应用密码将在弹窗中显示。复制该值，并确保它存放在安全的位置：

图 8.20 – 生成的应用程序密码

一个安全的位置示例是安全变量。将应用密码设置为安全的仓库变量或安全的工作区变量：

图 8.21 – 将应用密码添加为安全的仓库变量

1. 以下代码行需要添加到 bitbucket-pipelines.yml 文件的 script 部分，在 git 命令之前，以便您可以将更改保存并提交回 git 仓库。此行配置 git 远程 URL，使用包含的用户名和应用密码进行身份验证：

   git remote set-url origin https://<your username>:${APP_SECRET}@bitbucket.org/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}
   

到目前为止，我们已经学习了在提交更改到 git 仓库时如何使用几种身份验证方法。现在，让我们看看需要添加哪些内容来执行实际的提交。

如何实现…

如果你正在使用预配置的 HTTP git 源来推送更改到 git 仓库，或者已经使用上述某种方法设置了身份验证，那么你需要做的唯一事情就是定义执行实际 git 提交和推送的脚本步骤。我们来看看如何实现：

1. 要提交更改，将 git add、git commit 和 git push 命令添加到 bitbucket-pipelines.yml 文件的 script 部分。请注意，关于 git 提交消息，你可以添加 [skip ci] 以避免管道执行的无限循环。以下代码片段展示了一个示例：

   pipelines:
      default:
         - step:
             script:
                - git add <changed files>
                - git commit -m "[skip ci] Updates added via Bitbucket Pipelines deploy"
                - git push
   

2. 如果你使用标签，可以添加 git tag 命令来创建新的标签。代码片段将类似于以下内容。在此示例中，由于我们引用了 BITBUCKET_BUILD_NUMBER 预定义变量，标签将包含构建号：

   pipelines:
      default:
         - step:
             script:
                - git add <changed files>
                - git commit -m "[skip ci] Updates added via Bitbucket Pipelines deploy"
                - git tag -am "Tag for release ${BITBUCKET_BUILD_NUMBER}" release-${BITBUCKET_BUILD_NUMBER}
                - git push
   

我们现在已经看到如何使用 git 仓库作为构建工件的存储库。坦率地说，当有像 JFrog 的 Artifactory 和 Sonatype 的 Nexus 这样的专用构件库工具时，这种方法会显得有些繁琐。在接下来的步骤中，我们将学习如何将构建工件部署到这些工具中进行存储和跟踪。

将构件推送到构件库工具中

像 Artifactory 和 Nexus 这样的构件库工具支持配置管理，这是一种将从持续集成管道中生成的构建工件存储并与其应用的环境进行跟踪的实践。

通过 Bitbucket Pipes，基本构建可以推送到 Artifactory 或 Nexus，这使你可以轻松地从 bitbucket-pipelines.yml 文件进行部署。更复杂的涉及 Maven 或 npm 的部署将在这里不予讨论，但我们会提供一些参考，以创建这些类型的部署。

准备工作

在使用 JFrog Artifactory 或 Sonatype Nexus 的 Pipes 时，有一些先决步骤需要定义。我们将逐一查看每个工具所需的步骤。

JFrog CLI 先决条件

JFrog Setup CLI Pipe 需要连接到 JFrog 平台服务器。让我们看看这个过程中涉及的步骤：

1. 确保运行器已安装 JFrog CLI。在编写本文时，版本应为 2.17.0 或更高。以下命令适用于 macOS 和 Linux 运行器，假设已安装 curl：

   curl -fL "https://getcli.jfrog.io?setup" | sh
   

2. 如果你正在使用 Windows 运行器，请使用以下命令。请注意，这里使用的是 PowerShell：

   powershell "Start-Process -Wait -Verb RunAs powershell '-NoProfile iwr https://releases.jfrog.io/artifactory/jfrog-cli/v2-jf/[RELEASE]/jfrog-cli-windows-amd64/jf.exe -OutFile $env:SYSTEMROOT\system32\jf.exe'" ; jf setup
   

3. 使用 JFrog CLI 连接到你的 JFrog 平台服务器。要设置 JFrog 平台实例的详细信息，请运行以下命令：

   JFROG_CLI_SERVER_ID.
   

4. 现在，可以方便地设置与 JFrog 环境变量相对应的 Bitbucket 安全变量，变量名以 JF_ENV_ 开头，键为环境变量名，值为服务器令牌。你可以通过以下 JFrog CLI 命令获取服务器令牌：

   jf c export <server ID from previous instruction>
   

到此为止，我们已经覆盖了 JFrog CLI 的初步设置。现在，我们来看一下 Nexus 需要的内容。

Sonatype Nexus 先决条件

Sonatype Nexus 发布器的管道需要定义一些环境变量。某些变量是必填的。需要定义的变量如下：

• FILENAME（必填）：这是要发布的文件路径。

• ATTRIBUTES（必填）：Nexus 发布器所需的属性。组件属性以 -C 表示，资产属性以 -A 表示。

• USERNAME（必填）：Nexus 用户名。

• PASSWORD（必填）：Nexus 密码。

• SERVER_URL（必填）：Nexus 服务器 URL。

• REPOSITORY：Nexus 中的仓库名称。默认值是 maven-releases。

• FORMAT：制品格式。默认值是 maven2。

既然先决条件已经处理完毕，接下来我们来看一下如何使用管道推送我们的制品。

如何操作……

在 第六章 的 连接到 Bitbucket 管道 章节中，我们了解了管道。管道作为 Bitbucket 管道中的第三方工具集成点。

现在，我们已经准备好通过管道连接到 JFrog 或 Sonatype Nexus，并设置部署步骤。让我们来看看如何为每个工具执行这项操作。

使用 JFrog Setup CLI 管道

你可以使用 JFrog Setup CLI 管道连接到 JFrog 平台上的任何 JFrog 工具，包括 Artifactory 和 XRay。我们来看一下相关步骤：

1. 将以下几行添加到 bitbucket-pipelines.yml 文件的 script 部分：

   script:
      - pipe: jfrog/jfrog-setup-cli:2.0.0
      - source ./jfrog-setup-cli.sh
   

2. 一旦添加了设置行，你就可以使用任何 JFrog CLI 命令进行更改。以下代码片段是一个示例，展示了一个构建过程，该过程通过 JFrog CLI 命令将多个命令发送到 Artifactory：

   script:
      - pipe: jfrog/jfrog-setup-cli:2.0.0
      - source ./jfrog-setup-cli.sh
      # Upload artifacts to Artifactory
      - jf rt u file artifacts/
      # Collect environment variables
      - jf rt bce
      # Publish build info
      - jf rt bp
   

到此为止，我们已经学会了如何使用管道和 JFrog CLI 命令与 JFrog 工具进行连接和通信。现在，我们来看一下 Sonatype Nexus 管理器的过程。

使用 Sonatype Nexus 发布器管道

让我们学习如何使用管道连接到 Sonatype Nexus 发布器：

1. 将以下代码片段添加到 bitbucket-pipelines.yml 文件的 script 部分。你可以直接在代码中填写变量，或者使用 Bitbucket 变量：

   - pipe: sonatype/nexus-repository-publish:0.0.1
     variables:
       FILENAME: '<string>'
       ATTRIBUTES: '<string>'
       USERNAME: '<string>'
       PASSWORD: '<string>'
       SERVER_URL: '<string>'
       # REPOSITORY: '<string>' # Optional.
       # FORMAT: '<string>' # Optional.
   

2. 这是一个示例：

       - step:
           # set NEXUS_USERNAME and NEXUS_PASSWORD as environment variables
           name: Deploy to Nexus Repository Manager
           deployment: test   # set to test, staging or production
           # trigger: manual  # uncomment to have a manual step
           script:
             - pipe: sonatype/nexus-repository-publish:0.0.1
               variables:
                 FILENAME: 'target/myapp-1.0-SNAPSHOT.jar'
                 ATTRIBUTES: '-CgroupId=com.example -CartifactId=myapp -Cversion=1.0 -Aextension=jar'
                 USERNAME: '$NEXUS_USERNAME'
                 PASSWORD: '$NEXUS_PASSWORD'
                 SERVER_URL: 'https://nexus.example.com/'
   

到目前为止，我们已经看到使用管道进行轻松部署是多么简单。本章后续的其他示例也将展示管道的简便性。

另见

以下是一些其他参考资料链接，如果你需要了解更多关于如何连接到 JFrog 或 Sonatype Nexus 的信息：

• JFrog CLI 文档：docs.jfrog-applications.jfrog.io/jfrog-applications/jfrog-cli

• 使用 Bitbucket Pipelines 进行 Maven 部署的示例，使用GNU 隐私保护（GPG）和开源软件仓库托管（OSSRH）：bitbucket.org/simpligility/ossrh-pipeline-demo/src/master/

接下来，我们将看几个将构建构件安装到目标环境的示例。我们将从查看各种上传过程开始。

将构件部署到 Bitbucket 下载区

你可以通过配置 Bitbucket 下载管道，将 Bitbucket 本身作为构建构件的暂存区。这使你能够将构建构件推送到 Bitbucket 下载区。我们将在本食谱中更详细地了解这一过程。

准备就绪

使用bitbucket-upload-file管道需要通过用户名和应用密码或访问令牌进行身份验证。我们在准备就绪部分中查看了如何创建应用密码，这部分内容出现在将构件推送到 Bitbucket 仓库的食谱中。

访问令牌在所有 Bitbucket 计划的仓库级别都可用，并且在 Bitbucket 的 Premium 计划下，项目和工作区级别也可以使用。令牌仅限于为其创建的仓库、项目或工作区。这些令牌是一次性使用的，如果需要替换，则会被撤销。让我们学习如何创建一个仓库访问令牌：

1. 在仓库级别，选择侧边栏中的仓库设置。

2. 在仓库设置侧边栏中，选择安全部分中的访问令牌：

图 8.22 – 选择访问令牌

1. 在访问令牌页面，选择创建仓库 访问令牌：

2. 在弹窗中，为令牌命名并指定权限。Bitbucket Pipelines 要求读取和写入仓库权限。完成后，点击创建：

3. 接下来的弹窗将包含令牌的值以及相关的有用应用。通过复制令牌并粘贴到安全的位置来保存令牌值。这将是你查看令牌值的唯一机会。

4. 你可以将访问令牌作为安全的仓库变量。选择仓库设置侧边栏中的仓库变量，填写令牌的键名，并将之前复制的令牌值粘贴到值部分。一旦完成，勾选已加密复选框并点击添加：

图 8.23 – 仓库变量

现在我们已经建立了身份验证方式，无论是通过用户名/应用密码还是访问令牌，接下来让我们设置管道以将文件上传到 Bitbucket 下载区。

如何操作…

bitbucket-upload-file管道是将文件部署到 Bitbucket 下载区的主要方式。让我们来学习如何设置这个管道：

1. 如果你想使用用户名和应用密码进行身份验证，请使用以下代码片段：

   script:
     - pipe: atlassian/bitbucket-upload-file:0.7.1
       variables:
         BITBUCKET_USERNAME: $BITBUCKET_USERNAME
         BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
         FILENAME: 'package.json'
   

2. 如果改用访问令牌，请将 BITBUCKET_USERNAME 和 BITBUCKET_APP_PASSWORD 替换为 BITBUCKET_ACCESS_TOKEN。以下代码片段展示了这一点：

   script:
     - pipe: atlassian/bitbucket-upload-file:0.7.1
       variables:
         BITBUCKET_ACCESS_TOKEN: $BITBUCKET_ACCESS_TOKEN
         FILENAME: 'package.json'
   

3. FILENAME 管道变量可以通过调用通配符来指定多个文件。注意，限制为 10 个文件。以下代码展示了上传所有 .txt 文件的示例：

   script:
     - pipe: atlassian/bitbucket-upload-file:0.7.1
       variables:
         BITBUCKET_USERNAME: $BITBUCKET_USERNAME
         BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
         FILENAME: '*.txt'
   

4. 其他可选的管道变量允许你指定另一个帐户和仓库来上传文件。ACCOUNT 和 REPOSITORY 在以下代码片段中展示：

   script:
     - pipe: atlassian/bitbucket-upload-file:0.7.1
       variables:
         BITBUCKET_USERNAME: $BITBUCKET_USERNAME
         BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
         FILENAME: 'package.json'
         ACCOUNT: $PROJECT_ACCOUNT
         REPOSITORY: $ALTERNATE_REPO
   

到此为止，我们已经学会了如何将文件推送到 Bitbucket 下载区以便取回。现在，让我们学习如何将构建产物发送到目标服务器。

使用 SCP 部署构建产物

SCP 是在两台主机之间传输文件的一种方式。该协议使用 SSH 作为基础，安全地将文件从一台计算机移动到另一台计算机。

让我们学习如何使用 SCP 将构建产物从 Bitbucket Cloud 传输到远程主机。

准备工作

由于 SCP 的基础是 SSH，我们需要准备一个 SSH 密钥，并在 Bitbucket 和远程主机上配置与 SSH 相关的其他设置。让我们看一下所需的步骤：

1. 我们在推送构建产物到 Bitbucket 仓库这一食谱的准备工作部分定义了一个仓库 SSH 密钥。我们可以通过复制公钥并将其放入 ~/.ssh/authorized_keys 文件中，使用该密钥进行远程主机的传输。如果你有远程主机的 SSH 访问权限，可以在生成密钥对的机器上运行以下命令。这确保执行此操作的用户是你：

   ssh-copy-id -i <public key file to copy> user@host
   

2. 我们还需要更新 Bitbucket 上的已知主机。对于仓库，位置与我们用来创建 SSH 密钥的屏幕相同。在仓库设置中，选择SSH 密钥。在SSH 密钥屏幕上，输入远程主机的 IP 地址并点击获取。

图 8.24 – 添加已知远程主机

1. 配置你的远程主机，允许在所需端口（默认是22）上进行 SCP/SSH 访问，并允许使用 SSH 密钥进行访问。由于存在多种系统和配置，这一步骤留给你作为练习。

一旦我们拥有必要的配置，就可以配置 bitbucket-pipelines.yml 文件了。

如何操作...

现在，我们已经在 Bitbucket Cloud 和远程主机上配置了 SSH 密钥，接下来可以设置 Bitbucket Pipelines，将文件传输过程变成一个部署过程：

1. 将以下代码片段添加到 bitbucket-pipelines.yml 文件的 script 部分。所需的管道变量包括远程主机的用户名、远程主机名称、远程主机上部署文件的路径，以及构建产物所在的本地路径：

   - pipe: atlassian/scp-deploy:1.5.0
     variables:
       USER: '<string>'
       SERVER: '<string>'
       REMOTE_PATH: '<string>'
       LOCAL_PATH: '<string>'
       # SSH_KEY: '<string>' # Optional.
       # EXTRA_ARGS: '<string>' # Optional.
       # DEBUG: '<boolean>' # Optional.
   

2. 你还可以使用 EXTRA_ARGS 管道变量添加选项。以下代码片段展示了一个示例：

   script:
     - pipe: atlassian/scp-deploy:1.5.0
       variables:
         USER: 'ec2-user'
         SERVER: '127.0.0.1'
         REMOTE_PATH: '/var/www/build/'
         LOCAL_PATH: 'build/'
         DEBUG: 'false'
         EXTRA_ARGS: ["-P", "8022"]
   

3. SSH_KEY管道变量允许你定义一个替代的 SSH 密钥。它应该是一个 base64 编码的私钥，保存为安全的 Bitbucket 变量。以下代码片段展示了如何使用替代 SSH 密钥：

   script:
     - pipe: atlassian/scp-deploy:1.5.0
       variables:
         USER: 'ec2-user'
         SERVER: '127.0.0.1'
         REMOTE_PATH: '/var/www/build/'
         LOCAL_PATH: 'build'
         SSH_KEY: $MY_SSH_KEY
         DEBUG: 'true'
         EXTRA_ARGS: ['-o', 'ServerAliveInterval=10']
   

至此，我们已经通过 Bitbucket Pipelines 部署到了目标环境。目前，目标环境是物理服务器或虚拟机。接下来，我们将学习如何部署到公共云环境。

部署构建产物到 AWS S3 存储桶

在这个示例中，我们将看看如何部署到 AWS。根据构建产物的类型，Bitbucket Pipelines 有多种管道可以部署到特定的 AWS 组件服务。

让我们看看将构建产物部署到 AWS S3 存储桶中需要涉及的内容。这是使用 Bitbucket Pipelines 进行部署的典型用例。

准备工作

在设置用于部署到 AWS S3 存储桶的管道时，你需要做的唯一事情是设置以下变量：

• AWS_ACCESS_KEY_ID：你的 AWS 访问密钥 ID。

• AWS_SECRET_ACCESS_KEY：你的 AWS 密钥访问密钥。它应该作为一个安全变量保存。

• AWS_DEFAULT_REGION：资源的默认 AWS 区域。

现在这些已经定义了，让我们来看一下如何设置管道。

如何操作…

此时，我们需要将管道配置添加到bitbucket-pipelines.yml文件的script部分。让我们更详细地看一下：

1. 将以下代码片段添加到bitbucket-pipelines.yml文件的script部分。这将包含你在准备工作部分设置的变量，并将其纳入script部分。这里，S3_BUCKET定义了目标存储桶，LOCAL_PATH定义了构建产物的位置：

   script:
     - pipe: atlassian/aws-s3-deploy:1.6.0
       variables:
         AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
         AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
         AWS_DEFAULT_REGION: 'us-east-1'
         S3_BUCKET: 'my-bucket-name'
         LOCAL_PATH: 'build'
   

2. 你还可以通过附加路径到在S3_BUCKET中定义的存储桶，来定义存储桶中的文件夹。以下代码片段演示了这一点：

   script:
     - pipe: atlassian/aws-s3-deploy:1.6.0
       variables:
         AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
         AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
         AWS_DEFAULT_REGION: 'us-east-1'
         S3_BUCKET: 'my-bucket-name/logs'
         LOCAL_PATH: '$(pwd)'
   

通过这些，你已经了解了如何轻松地将 Bitbucket Pipelines 连接到 AWS，从而部署构建产物。接下来，让我们看看如何在 Google Cloud 上做同样的事情。

部署构建产物到 Google Cloud

Bitbucket Pipelines 可以通过集成与这些服务的管道，向 Google 服务进行部署。以下是与 Google 服务连接的当前管道列表：

• Firebase 部署

• Google App Engine 部署

• Google Cloud Storage 部署

• Google Artifactory 注册（GAR）推送镜像

• Google Kubernetes Engine kubectl run

让我们更详细地看一下如何使用 Google Cloud Storage 部署管道来部署构建产物。

如何操作…

我们可以通过执行以下步骤将构建产物部署到 Google Cloud Storage：

1. 在你打算部署到 Google Cloud Storage 的step部分的script区域中，复制并粘贴pipe定义。Google Cloud Storage 部署管道的定义如下所示：

   - pipe: atlassian/google-cloud-storage-deploy:2.0.0
     variables:
       KEY_FILE: '<string>'
       BUCKET: '<string>'
       SOURCE: '<string>'
       # GOOGLE_OIDC_CONFIG_FILE: "<string>" # Optional by default. Required for OpenID Connect (OIDC) authentication.
       # PROJECT: "<string>" # Optional by default. Required with GOOGLE_OIDC_CONFIG_FILE.
       # CACHE_CONTROL: '<string>' # Optional. options include no-cache,no-store,max-age=<seconds>, s-maxage=<seconds>, no-transform, public, private
       # CONTENT_DISPOSITION: '<string>' # Optional.
       # CONTENT_ENCODING: '<string>' # Optional.
       # CONTENT_LANGUAGE: '<string>' # Optional.
       # CONTENT_TYPE: '<string>' # Optional.
       # ACL: '<string>' # Optional.  Options include project-private, private, public-read, public-read-write, authenticated-read, bucket-owner-read, bucket-owner-full control
       # STORAGE_CLASS: '<string>' # Optional.  Options include multi-regional, regional, nearline, coldline
       # DEBUG: '<boolean>' # Optional.
   

2. 将管道添加到 bitbucket-pipelines.yml 文件的 script 部分。以下代码片段展示了只提供必需管道变量的示例：

   script:
     - pipe: atlassian/google-cloud-storage-deploy:2.0.0
       variables:
         KEY_FILE: $KEY_FILE
         BUCKET: 'my-bucket'
         SOURCE: 'myApp.jar'
   

3. 如果需要，请继续通过添加其他变量来定义部署操作。以下代码片段展示了一个填充了更多变量的管道：

   script:
     - pipe: atlassian/google-cloud-storage-deploy:2.0.0
       variables:
         KEY_FILE: $KEY_FILE
         BUCKET: 'my-bucket'
         SOURCE: 'myAppFile.jar'
         CACHE_CONTROL: 'max-age=60'
         CONTENT_DISPOSITION: 'attachment'
         ACL: 'public-read'
         STORAGE_CLASS: 'nearline'
   

我们刚刚看到了使用管道将部署集成到 Google Cloud 资源中的示例。现在，让我们看一下与 Microsoft Azure 集成的示例。

部署工件到 Microsoft Azure

Bitbucket Pipelines 可以通过与这些服务集成的管道执行对 Azure 服务的部署。以下是当前与 Microsoft Azure 连接的管道列表：

• Azure CLI

• Azure 容器应用程序部署

• Azure ACR 推送镜像

• Azure Functions 部署

• Azure Kubernetes 服务部署

• Azure Kubernetes 服务 Helm 部署

• Azure 存储部署

• Azure Web Apps 容器部署

• Azure Web Apps 部署

让我们看看使用 Azure Functions 部署管道作为部署到 Microsoft Azure 的示例所需的内容。

准备中

在使用 Azure Functions 部署管道将部署到 Microsoft Azure 之前，我们需要建立 Azure 凭证。请按照以下步骤操作：

1. 在本地计算机上安装 Azure CLI 或使用 Azure Cloud Shell 后，通过输入以下命令来创建 Azure 安全主体：

   az ad sp create-for-rbac --name <name of your service principal>
   

2. 上述命令将返回以下 JSON 格式的输出：

   {
     "appId": "myAppId",
     "displayName": "myServicePrincipalName",
     "password": "myServicePrincipalPassword",
     "tenant": "myTentantId"
   }
   

3. 将输出保存为仓库变量。例如，您可以按如下方式将以下输出定义为变量：

   • appId: AZURE_ID

   • password: AZURE_PASSWORD（已加密）

   • tenant: AZURE_TENANT

现在我们已经有了安全主体，可以使用 Bitbucket Pipelines 连接到 Azure。让我们来学习如何操作。

如何操作…

Azure Functions 部署将通过您最喜爱的 Microsoft 开发工具（如 Visual Studio）编写的无服务器逻辑实现，打包后在 Azure 中按需执行。开发过程的一部分可以包括通过 Bitbucket Pipelines 进行部署。让我们学习如何从 bitbucket-pipelines.yml 文件部署功能：

1. 将以下代码片段添加到 bitbucket-pipelines.yml 的 script 部分。所需的参数包括安全主体的属性、在 Azure 中找到的功能名称以及包含要在 Azure 部署的功能的 ZIP 文件名：

   script:
     - pipe: atlassian/azure-functions-deploy:2.0.0
       variables:
         AZURE_APP_ID: $AZURE_APP_ID
         AZURE_PASSWORD: $AZURE_PASSWORD
         AZURE_TENANT_ID: $AZURE_TENANT_ID
         FUNCTION_APP_NAME: '<string>'
         ZIP_FILE: '<string>'
         # DEBUG: '<boolean>' # Optional
   

2. 继续将必要的变量添加到管道定义中。完成的示例可以参考以下内容：

   script:
     - pipe: atlassian/azure-functions-deploy:2.0.0
       variables:
         AZURE_APP_ID: $AZURE_APP_ID
         AZURE_PASSWORD: $AZURE_PASSWORD
         AZURE_TENANT_ID: $AZURE_TENANT_ID
         FUNCTION_APP_NAME: 'my-function'
         ZIP_FILE: 'application.zip'
   

有了这些，我们已经将一个无服务器功能从本地系统部署到了 Azure。

部署的一个方面是 基础设施即代码 (IaC)，即使用基于文本的配置动态创建所需资源。一种流行的工具是 Ansible。在下一个食谱中，我们将学习如何使用 Bitbucket Pipelines 执行 Ansible playbook 并部署资源。

在部署阶段使用 Ansible

Ansible 是执行基础设施即代码（IaC）的标准工具。通过 Ansible，你可以配置物理或虚拟服务器，并执行配置任务，如安装或升级软件、设置必要的参数、启动应用服务等。

Ansible 既可以通过原始的命令行接口（CLI）使用，也可以通过一个名为 Ansible Tower 的集成图形用户界面（GUI）为专用的 Ansible 应用服务器提供服务。我们将学习如何自动化部署到这两个接口。

准备工作

要执行 Ansible，必须在你计划用于执行 Bitbucket 流水线的运行器上安装以下程序：

• python

• pip

一旦它们安装完成，我们可以将 Ansible 命令添加到 Bitbucket 流水线中。

如何操作…

原始的 Ansible 应用程序基于 Python 构建，接受两个输入文件。这两个文件都是 YAML 格式的文本文件：

• playbook：该文件包含 Ansible 执行的命令

• Inventory：此文件详细列出了 Ansible 将 playbook 应用到的机器及其环境

让我们学习如何在 bitbucket-pipelines.yml 文件中整合这一操作：

1. 将以下行添加到 bitbucket-pipelines.yml 文件的 script 部分。这将安装 Ansible：

   - pip install ansible==2.17
   

2. 安装完成后，进入 Ansible playbook 所在的目录：

   -i flag to denote the inventory file:
   
   

   • ansible-playbook -i inventory playbook.yaml

3. 脚本应如下所示：

   script:
      - pip install ansible==2.17
      - cd deployment
      - ansible-playbook -i inventory playbook.yaml
   

在这个示例中，我们学习了如何使用社区版 Ansible 从 Bitbucket Pipelines 部署配置。来自 Red Hat 的完整版提供了一个专用的基础设施，用于运行由名为 Ansible Tower 的 GUI 控制的 Ansible 应用程序。接下来，我们将学习如何使用 Bitbucket Pipelines 部署到 Ansible Tower。

还有更多内容…

尽管控制 Ansible Tower 作业的主要方式是通过图形用户界面（GUI），但也有一个名为 tower-cli 的命令行工具，它允许你脚本化 Ansible Tower 作业。让我们来看一下 tower-cli 的实际操作：

1. 在你的构建环境中安装 tower-cli。你可能需要指定一个包含 Python 和 pip 的镜像。在这里，pip 允许你安装 tower-cli：

   image: python:2.7
     pipelines:
      default:
       - step:
           script: # Modify the commands below to build your repository.
               - pip install ansible-tower-cli
   

2. 设置所需的环境变量。对于 tower-cli，这些变量如下：

   • host：Tower 主机

   • username：Tower 用户名

   • password：Tower 用户密码（保存为安全的 Bitbucket 变量）

   • ID：要启动的 Tower 作业模板的 ID

3. 添加以下几行来配置环境变量并运行 Ansible 作业：

    - hostval=$(tower-cli config host $host)
    - userval=$(tower-cli config username $username)
    - passwordval=$(tower-cli config password $password)
    - tower-cli config verify_ssl false
    - tower-cli job launch --job-template $ID --monitor
   

有了这些，我们就触发了位于 Ansible Tower 中的 Ansible 作业，从 Bitbucket Pipelines 启动。

另见

以下是 Ansible 文档，提供了创建正确 Ansible 作业的指导：

• access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.4

• docs.ansible.com/ansible/latest/index.html

在部署阶段使用 Terraform

Terraform 是另一种提供 IaC 功能的工具。它的流行之处在于它能够灵活地概述云资源的实例创建，然后通过指定实施细节的提供程序将这些资源实施到特定的云平台。

让我们学习如何从 Bitbucket Pipelines 部署到 Terraform。

准备工作

Terraform 在三个文件中描述了它将执行的配置，这些文件都需要在您的 Bitbucket 仓库中：

• main.tf

• variables.tf

• provider.tf

此外，Terraform 配置后端平台所需的任何凭据，例如 AWS 或 Google Cloud，应该存储为 Bitbucket 变量，并在必要时将其设置为安全。

在这些步骤完成后，让我们设置我们的部署。

如何操作…

我们必须采取几个步骤才能使用 Terraform 部署，封装在三个命令中。让我们看一下我们需要使用的 Terraform 命令：

1. 对于定义部署的步骤，使用 Terraform Docker 镜像。我们将在第九章中更详细地介绍如何在 Bitbucket Pipeline 步骤中使用 Docker 镜像：

    - step:
       image: hashicorp/terraform:full
   

2. 在 bitbucket-pipelines.yml 文件的 script 部分中，输入以下命令来初始化 Terraform：

    - terraform init
   

3. 添加以下命令以执行验证。这可能不是必需的：

   -out flag:
   
   

   • terraform plan -out=plantf

4. 添加以下命令以应用计划并运行 Terraform：

   step should now look as follows:
   
   

   • step:

   image: hashicorp/terraform:full

   script:

   • terraform init

   • terraform validate

   • terraform plan -out=plantf

   • terraform apply plantf

通过这些步骤，我们在 Bitbucket Pipelines 中执行了部署，并调用 Terraform 创建了我们的实例。

另见

以下资源有助于理解 Terraform – developer.hashicorp.com/terraform/docs。

第九章：利用 Docker 和 Kubernetes 进行高级配置

在上一章中，我们探讨了通过 Bitbucket Pipelines 实现持续部署，并使用各种技术平台进行操作。然而，我们将 Docker 和 Kubernetes 部署的讨论留到现在。Bitbucket Pipelines 可以利用容器作为其构建环境、构建包，甚至作为运行器来执行流水线操作。在上述每种情况下，您可以使用公共镜像或创建并使用私有镜像。

在本章中，我们将探讨使用 Docker 容器技术和 Kubernetes。我们将在本章中实现 Bitbucket Pipelines 时，涵盖以下内容：

• 使用 Docker 镜像作为构建环境

• 在 Bitbucket Pipelines 中使用容器化服务

• 在 Bitbucket Pipelines 中使用 Docker 命令

• 使用 Bitbucket Pipelines 将 Docker 镜像部署到 Kubernetes

• 在 Linux 上设置基于 Docker 的运行器

让我们开始在 Bitbucket Pipelines 中探索 Docker 和 Kubernetes。

技术要求

在我们开始探索之前，我们应该先明确在本地开发环境中工作所需的 Docker 和 Kubernetes 工具。

要使用 Docker 镜像，需要确保在您的运行器机器上安装了 Docker 应用，以执行任何 Docker 命令。

对于用于创建构建环境的开发机器，Docker Desktop 是一个不错的选择，它提供了所有必需的 Docker 工具，用于构建、打包、运行和部署容器化应用。它适用于 Mac、Windows 和 Linux 操作系统。更多信息请参考 docs.docker.com/get-docker/。

运行器只需要能够构建和运行容器化应用的 Docker 应用。因此，Docker Engine 是一个很好的应用，适合安装并配置在您的运行器上。它支持许多常见的 Linux 发行版，包括 Ubuntu、Debian 和 Red Hat。更多信息请参考 docs.docker.com/engine/。

在处理 Kubernetes 集群时，kubectl 是首选工具。可以为 Linux、Mac 或 Windows 下载 kubectl 的二进制文件。像 Red Hat Linux 的 yum、Debian Linux 的 apt、Mac 的 homebrew 和 Windows 的 chocolatey 等包管理器也可以下载并安装 kubectl。更多信息请参考 kubernetes.io/docs/home/。

本章的示例代码可以在本书 GitHub 仓库的 Chapter9 文件夹中找到 github.com/PacktPublishing/Atlassian-DevOps-Toolchain-Cookbook/tree/main/Chapter9

引入容器和 Bitbucket Pipelines

促进 DevOps 运动的最新技术进展之一就是 容器 技术的引入。如在 第一章 中提到的，应用程序及其所需的库将驻留在一个自包含的实体中，称为容器，而不是像物理或 虚拟机（VMs）那样设置完整的环境。这个容器通过一个管理应用程序与外部资源进行交互。在撰写本文时，最流行的容器管理应用程序是来自 Docker Inc. 的 Docker 引擎。

容器使应用程序的可移植性达到了前所未有的水平。开发人员可以创建一个应用程序，将其打包为容器，并在管理该容器的测试环境中对应用程序进行测试。部署到生产环境时将使用相同的容器镜像，但在一个可能拥有更多资源的环境中，具体取决于目标，可以支持多个应用程序容器实例进行负载共享或高可用性。

Bitbucket Pipelines 可以与容器配合使用。那么，让我们来考虑一些容器在 Bitbucket Pipelines 中的用途。

默认情况下，Bitbucket Pipelines 使用 Docker 镜像作为构建环境。你可以定义用于构建的 Docker 镜像。

你还可以使用 Bitbucket Pipelines 创建 Docker 容器镜像，并更新相应的 Docker 容器仓库。

Bitbucket Pipelines 可以使用从 Docker 镜像创建的运行器来执行构建。这可能允许通过动态分配运行器来执行构建，创建所需数量的 Docker 容器，并在完成后销毁这些容器。唯一的限制是环境中可用的资源。

容器技术的另一个应用形式就是 Kubernetes。Kubernetes 最初由 Google 开发，用于将存储在容器中的应用程序抽象为服务，并提供一个环境来建立和维护容器化服务的集群。

最后，Bitbucket Pipelines 可以将应用程序构建为 Docker 容器镜像。这个镜像可以作为管道脚本的一部分部署到 Kubernetes 集群中。

现在我们了解了 Docker 容器如何与 Bitbucket Pipelines 配合工作，让我们来看看如何实现这一点。

使用 Docker 镜像作为构建环境

Bitbucket Pipelines 使用 Docker 镜像作为平台来执行 bitbucket-pipelines.yml 中的命令。该镜像通常是由 Atlassian 提供的默认镜像，但也可以替换为自定义镜像。

让我们来看看 Bitbucket Pipelines 如何使用这些 Docker 镜像。

准备工作

在 Bitbucket Pipelines 中，运行器在构建环境中执行 bitbucket-pipelines.yml 中指定的命令。这个构建环境始终使用 Docker 容器。

如果没有指定 Docker 镜像，Bitbucket Pipelines 将选择一个默认的 Docker 镜像用于容器。

Bitbucket Pipelines 使用的默认镜像由 Atlassian 存储在 Docker Hub 上，网址是 hub.docker.com/r/atlassian/default-image/。

默认镜像的版本号可以被指定。如果未指定版本号，则会使用带有 latest 标签的版本。

以下表格提供了默认镜像版本的概览：

版本	标签	内容
1.x（不推荐使用）	latest	平台：ubuntu 14.04 开箱即用的软件包：wget xvfb curl git: 1.9.1 java: 1.8u66 maven: 3.0.5 node: 4.2.1 npm: 2.14.7 nvm: 0.29.0 python: 2.7.6 gcc: 4.8.4
2.x（不推荐使用）		平台：ubuntu 16.04 开箱即用的软件包：wget xvfb curl ssh git: 2.7.4 mercurial: 3.7.3 java: Open-JDK 1.8u151 maven: 3.3.9 node: 8.9.4 npm: 5.6.0 nvm: 0.33.8 python: 2.7.12 gcc: 5.4.0 ant: 1.9.6
3.x（不推荐使用）		平台：ubuntu 20.04 (LTS) 开箱即用的软件包：wget xvfb curl ssh zip jq tar parallel git: 2.39.1 node: 14.17.5 npm: 6.14.14 nvm: 0.38.0 python: 3.8.10 gcc: 9.4.0 ant: 1.10.7
4.x（推荐使用）		平台：ubuntu 22.04 (LTS) 开箱即用的软件包：wget xvfb curl ssh zip jq tar parallel git: 2.39.1 node: 18.16.1 npm: 9.5.1 nvm: 0.39.2 python: 3.10.6 gcc: 11.3.0 ant: 1.10.12

表 9.1 – 默认的 Atlassian 构建环境 Docker 镜像

重要提示

标记为 latest 的镜像使用的是较旧的镜像，其他镜像则是更近期创建的。这确保了与旧版 Bitbucket Pipelines 构建的向后兼容性。

要指定所需版本，请将以下行添加到 bitbucket-pipelines.yml 文件中：

image: atlassian/default-image:<version number>

这里，<version number>表示所需的版本或标签（例如 latest）。

我们可以指定任何来自公共或私有仓库的 Docker 镜像来创建我们的构建环境。让我们在下一部分中探讨如何做到这一点。

如何操作…

Bitbucket Pipelines 可以使用来自公共或私有仓库的任何 Docker 镜像。所需的信息依据仓库是公共还是私有而有所不同。

让我们学习如何使用来自公共注册表的 Docker 镜像。

使用公共镜像

公共仓库托管着任何人都可以使用的 Docker 镜像。该仓库可以托管在 Docker Hub 上，也可以是其他仓库，甚至是自发布的仓库，只要它可以通过互联网访问。

让我们来看一下如何使用公共 Docker 镜像作为构建环境：

1. 在 bitbucket-pipelines.yml 文件中通过名称指定镜像。如果没有包含标签，则默认使用 latest 标签：

   image: postgres
   

2. 如果指定了账户，它应作为名称的一部分：

   image: bitnami/postgresql
   

3. 可以在镜像名称后添加冒号和特定版本：

   image: bitnami/postgresql:16.2.0
   

4. 如果使用的公共镜像不托管在 Docker Hub 上，请在镜像规范中包含仓库的 URL：

   image: docker.publicimage.com/bitnami/postgresql:16.2.0
   

这样，你就学会了如何为构建环境指定公共 Docker 镜像。接下来，我们来看看如何使用私有镜像。

使用私有镜像

私有 Docker 仓库通常由公司和其他组织用来存储包含该组织知识产权的自定义 Docker 镜像。这些仓库通常通过认证策略来进行保护。

我们来看看如何通过使用私有 Docker 镜像来配置构建环境：

1. 你可以添加安全变量来存储你的凭证，并在bitbucket-pipelines.yml文件中引用这些变量。关于变量和秘密的内容可以参考第六章。以下代码片段展示了一个私有 Docker Hub 仓库的示例：

   image:
      name: my-company-account/bitnami/postgresql:16.2.0
      username: $DOCKER_HUB_USERNAME
      password: $DOCKER_HUB_PASSWORD
      email: $DOCKER_HUB_EMAIL
   

2. 如果你的私有 Docker 仓库使用 AWS aws 部分：

   image:
      name:
   <aws_account_id>.dkr.ecr.<region>.amazonaws.com/bitnami/postgresql:16.2.0
      aws:
         access-key: $AWS_ACCESS_KEY
         secret-key: $AWS_SECRET_KEY
   

3. 传递 AWS 凭证的另一种方法是通过在 AWS 中设置 IAM 角色，并将 Bitbucket Pipelines 配置为 Web 身份提供者。这使得 Bitbucket Pipelines 能够使用 Open ID Connect 连接到 AWS ECR。详细说明可以参考support.atlassian.com/bitbucket-cloud/docs/use-aws-ecr-images-in-pipelines-with-openid-connect/。接下来，必须将以下代码片段放入bitbucket-pipelines.yml文件中：

   image:
      name: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/bitnami/postgresql:16.2.0
      aws:
             oidc-role: arn:aws:iam::<aws_account_id>:role/<your_role_name>
   

4. 如果你的私有 Docker 仓库位于 Google Container Registry (GCR) 中，你必须在 GCP 管理控制台中创建一个服务账户，并授予 Bitbucket Pipelines 对 GCR 的 Viewer 访问权限。这样将创建一个 JSON 格式的私钥。下载该密钥并将其作为安全变量保存在 Bitbucket Pipelines 中。然后，你可以使用以下代码片段访问该镜像：

   image:
      name: <region>.gcr.io/<project>/image
      username: _json_key
      password: '$GCR_JSON_KEY'
   

   对于其他任何私有 Docker 仓库，请提供注册表 URL，并将凭证作为安全变量进行配置。以下代码片段展示了这一点：

   image:
      name: docker.<company name>.com/<account-name>/bitnami/postgresql:16.2.0
      username: $USERNAME
      password: $PASSWORD
      email: $EMAIL
   

通过这些，你已经看到 Bitbucket Pipelines 可以从多个地方获取 Docker 镜像来作为构建环境。

接下来，我们将学习如何在运行 Bitbucket pipeline 时定义和使用容器化服务。

在 Bitbucket Pipelines 中使用容器化服务

你可以通过定义要使用的容器在 Bitbucket pipeline 中运行多个服务。当 pipeline 运行时，这些服务将在被调用的步骤中按计划执行。可以通过这种方式调用的服务包括数据库、代码分析和 Web 服务。

在这个教程中，我们将学习如何定义和使用容器化服务。

准备开始

在 pipeline 执行过程中，使用容器化服务有一些限制需要理解。我们现在来详细看看这些限制。

这些容器化服务可用的资源是有限的。每个 pipeline 步骤最多可以使用五个服务。如果你需要使用更多服务，可以定义 docker run 或 docker-compose。

每个服务将会在没有等待服务启动的情况下运行。尽管这些服务正在运行，但你无法通过 REST API 调用访问服务或其日志，尽管日志应通过 Bitbucket Pipelines 提供。29418将被保留，无法用于外部操作。

服务的最复杂限制涉及内存。每个步骤可以定义为常规步骤（具有 4,096 MB 的内存限制）或大构建步骤（通过在步骤定义中添加size: 2x语句来定义），这将把内存限制提高到 8,192 MB。

步骤中的内存被分配为一个构建容器和步骤中定义的服务容器数量。构建容器需要至少 1,024 MB。这部分内存用于处理构建过程和 Bitbucket Pipelines 所需的任何开销。

剩余的内存将提供给服务容器。在构建容器分配内存后，服务容器将剩余 3,027 MB 或 7,128 MB。默认情况下，每个服务容器可以获得 1,024 MB 或一个自定义值，范围为 128 MB 到最大值。可以通过在服务定义中使用memory关键字来设置此值。

如果你的构建步骤包含 Bitbucket Pipes，它使用的是内置的 Docker 服务。默认情况下，这个 Docker 服务占用构建步骤的 1,024 MB 内存，但可以通过将内存设置为 128 MB 到最大值之间的自定义值来进行配置。

现在我们已经了解了这些限制，让我们学习如何定义可以在给定步骤上运行的服务。

如何做到……

以下是可以在构建步骤中定义的服务类型的一组示例。在本食谱中，我们将查看使用这些服务的示例：

• 数据库服务

• 数据存储服务（例如，NoSQL）

• Docker-in-Docker 服务

让我们看看如何定义这些服务。

定义一个容器化的数据库服务

让我们从一个具有所有默认值的数据库服务的定义开始：

1. 在definitions:部分，在services:中指定服务名称，使用image:关键字添加 Docker 镜像，并在variables:部分中添加必要的凭证（作为安全变量）。这应如下所示：

   definitions:
      services:
         mysql:
            image: mysql:5.7
            variables:
               MYSQL_DATABASE: test-db
               #set up password as secure variable and use here
                    MYSQL_ROOT_PASSWORD: $password
   

2. 要在步骤中使用服务，请将服务添加到步骤的services:部分。如下所示的代码片段：

   default:
      - step:
            services:
               - mysql
   

3. 要自定义内存分配，请在definitions:部分的memory:关键字后面添加所需的内存量（以 MB 为单位）。代码应如下所示：

   definitions:
      services:
         mysql:
            image: mysql:5.7
            memory: 2048 # double the mimimum
            variables:
               MYSQL_DATABASE: test-db
               #set up password as secure variable and use here
               MYSQL_ROOT_PASSWORD: $password
   

现在我们已经在构建步骤中运行了一个数据库服务，并且它的服务容器内存为 2,048 MB。

定义一个容器化的数据存储服务

让我们按照前一个示例中的方式创建我们的数据存储服务：

1. 在definitions:部分，设置services:中的服务名称，并使用image:关键字添加 Docker 镜像。这些添加应如下所示：

   definitions:
      services:
         redis:
            image: redis:3.2
   

2. 要在某个步骤中使用该服务，只需将其添加到该步骤的 services: 部分。我们还添加了一个基于该服务运行的命令。如下代码片段所示：

   default:
      - step:
            script:
               - redis-cli -h localhost ping
            services:
               - mysql
   

到此为止，我们已经学会了如何定义一个容器化服务并在构建步骤中使用它。

现在，让我们学习如何调用 Docker-in-Docker 服务。

定义 Docker-in-Docker 服务

让我们看看如何在构建步骤中运行 Docker 服务：

1. 在 definitions: 部分，在 services: 中设置服务名称。应该如下所示：

   definitions:
      services:
         docker:
   

2. 要在某个步骤中使用该服务，请将其添加到该步骤的 services: 部分。我们还添加了一个基于该服务运行的命令。如下代码片段所示：

   default:
      - step:
            script:
               - docker info
            services:
               - docker
   

3. 你可以为你的 Docker 服务指定自定义名称。定义服务时使用自定义名称，并将 type: 设置为 docker。以下代码片段展示了一个自定义 Docker 服务的详细示例，并包含内存大小的定制：

   definitions:
      services:
         my-docker:
            memory: 5120
            type: docker
   default:
      - step:
         services: my-docker
         size: 2x
         script:
            - docker info
   

到此为止，我们已经学习了如何在 Bitbucket Pipelines 中将 Docker 定义为一个服务。

接下来，我们将学习如何将 Bitbucket Pipelines 的输出作为 Docker 镜像部署并将其推送到 Docker 仓库。为此，我们需要了解如何执行 Docker 命令。让我们看看这如何操作。

在 Bitbucket Pipelines 中使用 Docker 命令

如果你的 Bitbucket 仓库中有一个 Dockerfile，你可以使用 Bitbucket Pipelines 构建镜像并将其推送到 Docker 仓库。你可以通过在 bitbucket-pipelines.yml 文件中执行 Docker 命令来实现这一点。让我们更详细地看看如何操作。

准备工作

在将 Docker 命令添加到 bitbucket-pipelines.yml 文件之前，我们需要启用以下配置：

• 允许访问 Docker 守护进程

• 启用 Docker BuildKit

这些配置是 bitbucket-pipelines.yml 文件的一部分。让我们看看它们的位置。

启用对 Docker 守护进程的访问

通过将 Docker 作为服务添加到某个步骤中，可以实现对 Docker 守护进程的访问，这种方法推荐使用，因为你可以跟踪整体管道正在运行多少个服务，或者也可以将 Docker 作为服务添加到所有步骤中。让我们看看每种方法是如何实现的：

1. 要将 Docker 作为构建步骤的服务使用，请确保它出现在该步骤的 services: 部分。如以下代码片段所示：

   pipelines:
     default:
       - step:
           script:
             - ...
           services:
             - docker
   

2. 要将 Docker 作为全局服务使用，需在 options: 部分添加 docker 并将其设置为 true，如下代码片段所示：

   options:
     docker: true
   

启用 Docker 守护进程访问时有一些需要注意的事项。默认情况下，Docker 被定义为一个服务，因此我们无需在 bitbucket-pipelines.yml 的 definitions: 部分重新定义它。

现在，创建 Docker 构建通常需要使用 Docker BuildKit。那么，让我们学习如何在 Bitbucket Pipelines 中使用 Docker BuildKit。

启用 Docker BuildKit

Docker BuildKit 是在使用 Docker Desktop 或 Docker Engine v23.0 及以上版本时构建的默认部分。我们希望确保启用它，以确保与这些版本的兼容性。所以，让我们探索如何使用 Docker BuildKit。

要启用 Docker BuildKit，确保将 DOCKER_BUILDKIT 环境变量设置为 1，如以下代码片段所示：

pipelines:
   default:
       - step:
         script:
            - export DOCKER_BUILDKIT=1
            - docker build .
         services:
            - docker

现在，让我们学习如何在 Bitbucket Pipelines 中使用 Docker 命令。

如何操作…

启用 Docker 和 Docker BuildKit 后，我们可以运行大多数 Docker 命令。出于安全原因，Bitbucket Pipelines 对可以运行的 Docker 命令以及其他 Docker 命令的模式进行了限制。有关限制的详细列表，请访问support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/。

与此同时，我们将考虑将 Docker 集成到 Bitbucket Pipelines 中的常见用例。这些包括以下内容：

• 从 Dockerfile 构建 Docker 镜像

• 从 Bitbucket 安全变量将秘密传递给 Docker BuildKit

• 从外部秘密管理器将秘密传递给 Docker BuildKit

• 将 Docker 镜像推送到 Docker 仓库

让我们来看看这些常见的用例。

从 Dockerfile 构建 Docker 镜像

启用 Docker BuildKit 后，Bitbucket Pipelines 可以构建 Docker 镜像。让我们详细了解一下：

1. 确保在你的 Bitbucket 仓库的根目录下存在一个 Dockerfile。

   你可能想将镜像名称指定为一个变量。

2. 在构建步骤的脚本部分添加以下行：

   - docker build -t $IMAGE_NAME .
   

完成这一步后，让我们进入下一个用例。

使用安全变量将秘密传递给 Docker BuildKit

如果我们需要将诸如凭据或 API 密钥等秘密传递给 BuildKit 构建，可以使用 Bitbucket 中的安全变量进行传递。下面是我们可以执行的操作：

1. 在 Bitbucket 中创建安全变量。

   SECRET as the secure variable:
   

   pipelines:
      default:
         - step:
               name: 'BuildKit and secure variables'
               script:
               # Enable BuildKit
              - export DOCKER_BUILDKIT=1
              # Pass the secure variable into Docker build and prevent caching
              - docker image build -t latest --secret id=SECRET --progress=plain --no-cache dockerfile
              services:
              - Docker
   

2. 在 Dockerfile 中，添加一个 RUN 指令，将安全变量挂载（使用 --mount=type=secret 标志）到默认的 Docker 秘密存储中 (/run/secrets/*)。以下代码片段展示了这一操作：

   FROM ubuntu:latest
   # Mount and print SECRET
   RUN --mount=type=secret, id=SECRET \
         cat /run/secrets/SECRET
   

还有另一种将秘密传递给 Docker BuildKit 的方法：使用外部秘密管理器。所以，让我们探索如何与外部秘密管理器一起工作。

使用外部秘密管理器将秘密传递给 Docker BuildKit

我们还可以连接到外部秘密管理器，例如 Hashicorp Vault 或 Google Cloud Secret Manager，将凭据或 API 密钥等秘密传递给 BuildKit 构建。让我们学习如何操作：

1. 在 bitbucket-pipelines.yml 文件中，从管理器获取秘密，将秘密放入管道文件中，添加 --secret 标志，并将源标识为管道文件。请记住，管道文件将在管道步骤完成并且容器被移除时被删除。以下代码片段展示了 SECRET 作为安全变量：

   pipelines:
      default:
         - step:
               name: 'BuildKit and external secret managers'
               script:
               # Enable BuildKit
              - export DOCKER_BUILDKIT=1
              # This is where the call to the external secret manager resides.  We assume here that it has added the secret to "/secret_file"
              # Pass the secure variable into Docker build and prevent caching
              - docker image build -t latest --secret id=SECRET,src=/secret_file --progress=plain --no-cache dockerfile
              services:
              - docker
   

2. 在 Dockerfile 中，添加一个 RUN 指令，挂载安全变量（使用 --mount=type=secret 标志），并将包含秘密的管道文件挂载到默认的 Docker 秘密存储区 (/run/secrets/*) 中。以下代码片段演示了这个过程：

   FROM ubuntu:latest
   # Mount and print SECRET
   RUN --mount=type=secret, id=SECRET,dst=/secret_file \
         cat /run/secrets/SECRET
   

通过这些步骤，我们已经构建了一个包含从外部来源获取的秘密的镜像。现在，让我们来看看你可以执行的各种操作，包括推送到 Docker 注册表。

将 Docker 镜像推送到 Docker 注册表

你可以将创建的镜像推送到 Docker Hub 或其他注册表，作为 Bitbucket Pipelines 脚本执行的一部分。请按照以下步骤操作：

1. 创建镜像名称、Docker 仓库用户名和 Docker 仓库密码的变量。用户名和密码应该是安全变量。

2. 向步骤的脚本部分添加命令，以部署 Docker 镜像。为此，你需要执行以下操作：

   1. 登录到 Docker 仓库。

   2. 通过 docker push 推送镜像。

   以下代码片段展示了如何构建并推送 Docker 镜像的基本示例：

   - step:
      name: Build
      script:
         # Build the Docker image (assumes the Dockerfile is at the root level of the repository)
         - docker build -t $IMAGE_NAME .
         # Authenticate with the Docker registry (this example is Docker Hub)
         - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD
         # Push the image to the Docker registry
         - docker push $IMAGE_NAME
      services:
         - docker
   

到此为止，我们已经学会了如何通过构建 Docker 镜像并将生成的镜像推送到 Docker 注册表来部署应用程序。接下来，我们可以进一步完善我们的示例，将 Docker 镜像部署到 Kubernetes 集群。我们将在下一节中介绍这个过程。

使用 Bitbucket Pipelines 将 Docker 镜像部署到 Kubernetes

在构建 Docker 镜像之后，可能的下一步是将其部署到 Kubernetes 集群。通过利用集群的冗余能力，我们可以在不发生服务中断的情况下进行应用程序的升级。

准备工作

本教程假设你已有一个手动创建的 Kubernetes 集群或 minikube 环境。

此外，你还必须手动定义一个部署，用于在 Kubernetes 中运行应用程序。所以，让我们学习如何创建一个部署。

确保应用程序名称和 Docker 注册表用户名可供轻松引用。执行 kubectl 命令，并包括必要的标志，如以下代码片段所示。这些标志将包括应用程序名称和 Docker 注册表名称作为镜像名称的一部分：

kubectl run <my.app> --labels="app=<my.app>" --image=<my.dockerhub.username>/<my.app>:latest --replicas=2 --port=8080

既然我们已经在 Kubernetes 中建立了部署，接下来让我们学习在使用 Bitbucket Pipelines 时，如何实现应用程序的持续部署。

如何操作…

我们可以通过两种方式将 kubectl 应用程序集成到 Bitbucket Pipelines 中：

• 使用管道进行集成

• 设置服务

让我们更详细地看看每种方法。

使用管道执行 kubectl

正如我们在第六章中看到的那样，Bitbucket Pipes 是与常见第三方工具和实用程序的预打包集成。它们可以轻松地添加到 Bitbucket Pipelines 步骤中，并通过单独的容器作为服务执行。

让我们学习如何将 kubectl 管道集成进去：

1. 设置kubeconfig文件以供读取。此文件需要进行Base64编码，然后存储为一个安全变量。你可以使用以下代码来实现：

   KUBE_CONFIG_BASE64=$(cat ~/.kube/config | base64)
   

2. 将管道添加到步骤的脚本部分。管道定义应该如下所示：

   - step:
      name: Deploy
      deployment: production
      script:
         -pipe: atlassian/kubectl-run:1.1.2
          variables:
             KUBE_CONFIG: $KUBE_CONFIG
             KUBECTL_COMMAND: 'apply'
             RESOURCE_PATH: 'deployment.yml
   

有了这一切，我们已经通过 Bitbucket Pipelines 使用管道部署到了 Kubernetes。

有时，我们需要执行与管道中提供的版本不同的kubectl版本。在这种情况下，从 Atlassian 提供的kubectl Docker 镜像中执行是更好的选择。引入不同版本的一个原因可能是为了确保与现有 Kubernetes 集群的兼容性，尤其是当集群使用的是旧版本时。现在，让我们探索这个选项。

使用 kubectl Docker 镜像执行 kubectl

Bitbucket Pipelines 也有一个版本的kubectl，它封装在自己的 Docker 镜像中。此镜像位于 Docker Hub 上，地址为hub.docker.com/r/atlassian/pipelines-kubectl，可以在 Bitbucket Pipelines 脚本中使用它来执行kubectl命令。

使用kubectl服务在 Kubernetes 上进行部署时，请执行以下步骤：

1. 在部署步骤中，使用image:关键字定义 Docker 镜像。

2. 设置我们的kubeconfig文件。这一次，我们将解码 Base64 来创建一个临时文件，并在执行后销毁该文件：

   echo $KUBECONFIG | base64 -d > kubeconfig.yml
   

3. 执行kubectl命令来应用应用程序的新版本：

   - kubectl --kubeconfig=kubeconfig.yml apply -f deployment.yml
   

4. 综合以上内容，我们得到以下代码片段：

   -step:
      name: Deploy to Kubernetes
      image: atlassian/pipelines-kubectl
      script:
         - echo $KUBECONFIG | base64 -d > kubeconfig.yml
         # Run deployment command using kubectl
         - kubectl --kubeconfig=kubeconfig.yml apply -f deployment.yml
   

   如在第八章的配置部署食谱中所示，你可以通过部署仪表板监控你的部署。

有了这一切，你已经学会了如何将我们的应用构建为 Docker 镜像并部署到 Kubernetes 环境中。

我们在探索如何利用 Docker 时的最后一步是从管道到运行器。因此，让我们学习如何在 Linux 上配置基于 Docker 的运行器。

在 Linux 上设置基于 Docker 的运行器

使用自托管运行器的这一应用提供了动态配置的极致体验。通过允许在 Docker 容器内运行器，我们可以根据需要添加或删除运行器。

我们将从 Linux 环境开始，安装 Docker，然后加载并运行 Bitbucket 运行器软件的 Docker 镜像。让我们来看一下设置基于 Docker 的运行器的完整过程。

准备工作

我们的 Linux 环境有一些先决条件，在继续之前必须先覆盖它们。首先，我们需要了解我们的 Linux 环境。此环境应具备以下特性：

• 你应该使用 64 位版本的 Linux。

• 至少需要为运行器主机分配 8 GB 的 RAM。如果你知道你需要更多空间（例如，由于更多的构建步骤），你应分配更多内存。

• 至少需要为运行器容器分配 512 MB 的内存。

• 必须安装 Docker v19.03 或更高版本。

按照这种方式设置好 Linux 环境后，我们需要查看 Atlassian 推荐的 Linux 环境最佳实践。Atlassian 推荐以下环境配置：

• 禁用交换空间在你的 Linux 环境中

• 配置 vm.swappiness

让我们更详细地看看这些建议。

禁用交换空间

根据你使用的 Linux 发行版，你可能没有安装必要的命令。如果以下命令在你的 Linux 环境中不可用，你可以使用该发行版推荐的包管理器进行安装：

1. 检查交换空间是否已启用：

   sudo swapon -sv
   

   如果交换空间已启用，现有的交换分区会显示在以下输出中：

   NAME      TYPE      SIZE   USED PRIO
   /dev/sda3 partition   2G 655.2M   -1
   

2. 通过执行以下命令禁用交换空间：

   /etc/fstab.
   

3. 重启你的 Linux 机器。

4. 重复这些步骤，直到不再出现交换分区。

到此为止，我们已经消除了一个交换存储源。然而，我们应该消除其他来源。为此，我们将查看配置 vm.swappiness。

配置 vm.swappiness

同样，一些 Linux 发行版可能没有指定以下步骤中的命令。如果是这种情况，使用 Linux 发行版推荐的包管理器安装所需的命令。

让我们仔细看看如何正确配置 vm.swappiness 来禁用交换空间：

1. 使用以下命令检查 vm.swappiness 的值：

   1, configure vm.swappiness by performing the following steps:1.  Open `/etc/sysctl.conf` and add `vm.swappiness=1` to its own line in the file.2.  Save your changes.3.  Reboot the Linux machine.
   

2. 如果后续检查 vm.swappiness 的值不是 1，请重复这些步骤，并确保在 /etc/sysctl.conf 中正确配置该设置。

下一步是为了保持 Linux 环境的正常运行，强烈建议定期清理过时的 Docker 容器镜像。让我们来看一下如何安排这个操作。

自动化清理过时 Docker 镜像的过程

我们的 Linux 环境应定期清除未使用的 Docker 镜像，以节省磁盘空间。我们希望确保在 Linux 环境中有足够的磁盘空间，以便我们可以继续操作我们的 runner 并确保它在 Bitbucket Pipelines 作业中可用。删除未使用 Docker 镜像的命令是 docker system prune -af。安排自动运行命令的常见方法是使用cron。让我们看看如何操作：

1. 对于正确的用户，使用以下命令打开他们的 crontab 文件：

   crontab file while setting up the correct frequency, dates, and times. The following example runs the command on Sundays at midnight:
   
   

   0 0 * * 0 docker system prune -af

2. 保存文件并退出编辑器。

到这里，我们已经通过 cron 自动化了未使用的 Docker 镜像删除。现在，轮到设置我们的 runner 了。

如何操作…

在完成初步步骤后，接下来是将我们的 Linux 环境连接到 Bitbucket，以便它可以作为一个 runner 使用。让我们看看如何操作：

1. 在 Bitbucket 中，定义一个新的 runner。通过点击屏幕右上角的管理齿轮，选择工作区设置来定义一个工作区 runner：

图 9.1 – 在 Bitbucket 中选择工作区设置

1. 在左侧菜单栏中，选择工作区运行器：

图 9.2 – 选择工作区运行器

或者，如果你是在为存储库设置运行器，请选择存储库，并在存储库的侧边栏中选择存储库设置。

图 9.3 – 选择存储库设置

1. 在存储库设置侧边栏中，选择Pipelines下的运行器。

图 9.4 – 选择运行器

1. 无论是选择工作区的运行器还是存储库的运行器，都可以通过选择添加 运行器按钮来创建运行器。

   在出现的模态框中，根据你的硬件平台选择Linux Docker (x86_64) 或 Linux Docker (arm64)，然后点击下一步。

图 9.5 – 在系统和架构下选择 Linux Docker

在下一个模态框中，复制显示的 Docker 命令并将其粘贴到 Linux 环境中的终端窗口中。该命令将访问 Docker 注册表以检索 Bitbucket Pipelines 运行器软件作为 Docker 镜像，并创建容器。

图 9.6 – 复制 Docker 命令以拉取运行器

1. 你可能希望在重新启动运行器时获取最新版本，或者仅仅是为了确保你拥有最新版本。要执行此更新，请在你的 Linux 环境中执行以下 docker pull 命令：

   docker image pull docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1
   

   启动运行器时，你可能会遇到以下错误：

   docker: Error response from daemon: docker: Error response from daemon: Conflict. The container name "/runner-76b247e7-b925-5e7b-9da2-1cda14c4ff2c" is already in use by container "c3403236e3af5962ed3a9b8771561bd2021974941cc8a89a40c6c66cecb18f53". You have to remove (or rename) that container to be able to reuse that name.
   docker run command:*   The `-v` flag and the directory, as seen on the host machine.*   The `-e` flag and the desired mount point inside the runner. You can use any desired mount point, but it must match the value of the `WORKING_DIRECTORY` environment variable.An example of using the `docker run` command is shown in the following code snippet:
   
   

   docker run [所有现有参数] -v /mydir:/mydir -e WORKING_DIRECTORY=/mydir

到此为止，我们已经为将来执行 Bitbucket Pipelines 设置了基于 Docker 的运行器。

第三部分：维护操作

发布后，焦点转向确保新特性和产品的环境保持与之前相同的性能、可扩展性和安全性。通过对性能进行度量，评估系统的运行状态以及它是否交付了承诺的价值，并将结果展示出来。

显示界面着重于可观察性，确保不仅仅是存在度量标准，还要确保这些度量标准对每个人可用且可见：开发人员、运维人员、站点可靠性工程师以及公司中的其他人员。

当问题发生时，这些领域的人员会聚集在一起合作解决问题并找到解决方案。

在这一部分，我们将探讨 Atlassian 工具（如 Jira、Opsgenie 和 Compass）如何协同工作，以及与其他工具一起如何为各个领域提供可观察性，并快速升级和解决问题。

本部分包含以下章节：

• 第十章**，通过持续部署和可观察性与运营团队协作

• 第十一章**，通过 CheckOps 在 Compass 中监控组件活动和指标

• 第十二章**，通过 Opsgenie 警报进行升级

第十章：通过持续部署和可观测性与运维协作

在本章中，我们将通过查看主要由运维人员使用的工具集成来完成 DevOps 的循环。使用 Jira 的开发人员可以通过将 Jira 与持续部署（CD）工具（如 Bitbucket、GitLab、GitHub 或 Jenkins）集成，查看部署结果。监控性能的可观测性工具，如 Dynatrace 和 Datadog，可以通过集成将 Jira 问题与它们关联。

本章包含以下教程：

• 将 Jira 与持续部署工具连接

• 将 Jira 与可观测性工具连接

技术要求

完成本章所需的内容：

• Jira

• 一个 GitLab 账户 (about.gitlab.com/)

• 一个 Datadog 账户 (www.datadoghq.com/)

将 Jira 与持续部署工具连接

在本教程中，我们将学习如何将 Jira 与 CD 工具集成，以查看部署状态。在第四章中，我们了解到持续集成（CI）是指对代码库进行增量改进或更改，并自动化测试和验证这些代码更改的实践。

CD 可以被看作是 CI 的扩展，处理自动化的基础设施配置和应用发布过程。

本教程的目标如下：

• 将 GitLab 仓库与 Jira 项目关联

• 将 Jira 集成到 GitLab SaaS 应用中

• 对代码库进行更新，执行合并请求，并部署代码

• 在 Jira 项目和问题中看到 GitLab 部署的反映

准备工作

要执行此教程，您需要以下内容：

• Jira 管理权限，以便添加 GitLab 应用

• 一个 GitLab 账户和包含实际或示例代码的仓库

如何操作…

我们将使用以下步骤来实现这个教程的目标：

1. 首先，我们需要确保所使用的 Jira 项目已启用部署功能。

图 10.1 – 为 Jira 项目启用部署

1. 接下来，我们需要验证 GitLab 和 Jira 的集成。在第四章中，我们介绍了 GitLab 和 Jira 的集成。如有需要，请参考该章节。

   一旦 GitLab 集成得到验证，我们将需要将 GitLab 仓库连接到 Jira 项目。

2. 在所需的 Jira 项目中，导航到项目设置 | 工具链。

   然后选择添加工具。

图 10.2 – 添加到项目工具链

您将看到从推荐工具列表中可用的GitLab for Jira Cloud选项。

1. 选择添加 到项目。

图 10.3 – 将 GitLab 添加到 Jira 项目

重要提示

GitLab 框已被添加到项目的现有工具列表中。现在，我们需要将 GitLab 中的仓库与项目关联，并将项目中与代码库相关的所有问题也关联起来。

1. 选择+ 添加代码 仓库选项。

图 10.4 – 添加 GitLab 代码仓库

由于 GitLab 已经与 Jira 集成，弹出窗口会显示一个下拉选项。选择下拉菜单并查看可用的 GitLab 仓库。你可以选择一个或多个仓库与 Jira 项目关联。

1. 在此示例中，我们选择了与移动应用程序代码库相关的仓库。

   选择一个仓库后，点击添加 仓库按钮。

图 10.5 – 选择 GitLab 仓库

现在工具链中的 GitLab 框反映了所选的仓库。

图 10.6 – 添加 GitLab 仓库

提示

现在，我们将 Jira 项目与 GitLab 仓库关联起来，我们需要查看项目中的问题。我们需要识别或创建一个新项目，以便将其与代码更改和部署关联起来。

当我们在 GitLab 中对代码库进行更改时，我们需要问题的关键字来添加到分支和提交评论中。这将告诉 GitLab 哪些问题与部署相关。这被称为智能提交（Smart Commits）。

在以下 Jira 示例中，我们有一个问题，关键值等于ACR-6。该问题当前位于进行中（IN PROGRESS）状态列。

图 10.7 – Jira 问题关键字

1. 现在，让我们回到 GitLab 并针对 ACR-6 问题对代码库进行一些更新。首先，我们将为特定的更改创建一个新的分支。在 GitLab 中，在代码菜单下，选择分支。

图 10.8 – GitLab 代码仓库分支

这将为你提供创建新分支的选项。

1. 在分支名称字段中，确保使用 ACR-6 问题关键字，这样我们可以将此更改与 Jira 中的问题关联。然后选择创建分支。

图 10.9 – 创建 GitLab 分支

1. 从新的分支中，我们将选择一些代码进行修改。在此示例中，我们将对 Python 脚本进行一些简单的更新。有几种方法可以执行这些代码修改。为了简单起见，我们将通过 Web IDE 打开代码。

图 10.10 – 在 Web IDE 中打开以修改代码

我们已更新代码，以显示四个月后的日期。

1. 当我们的更改完成后，可以点击源代码控制按钮，并将更改提交到我们的新分支。在提交消息中，重要的是再次使用问题键（ARC-6），以将此提交与关联的 Jira 问题联系起来。

图 10.11 – 修改然后提交代码

1. 在提交更改后，我们可以返回到 GitLab，然后执行合并请求，将代码拉回主分支并部署代码。

   选择创建合并请求。

图 10.12 – 创建合并请求

创建合并请求后，您将看到流水线进程正在运行。此示例定义的流水线包括构建、运行两个测试作业，最后将代码部署到生产环境。

然后可以将代码合并到主分支，并关闭合并请求。

图 10.13 – 代码合并

1. 合并请求和部署完成后，我们可以切换回 Jira 项目，看到问题已自动转换为已完成状态。

   我们还可以在项目左侧面板中选择部署菜单选项，查看所有部署情况。

图 10.14 – Jira 部署操作

我们可以在部署视图中看到刚刚执行的 ACR-6 部署。

图 10.15 – Jira 部署视图

如果选择并查看实际的 ACR-6 问题，我们可以看到所有关联的 GitLab 活动。提交和合并请求显示在Web 链接部分下。单击其中任何链接将带您转到 GitLab 中的相应工件。

提示

您还可以查看开发面板，并查看所有关联的提交、构建和发布。

图 10.16 – Jira 问题开发人员视图

您现在已成功将 CD 应用程序（GitLab）集成到 Jira 中。这将增加跟踪代码发布过程中整体可见性。

将 Jira 与可观察性工具连接起来

DevOps 可观察性是 DevOps 中的一种实践，专注于深入了解应用程序和基础设施的行为、性能和健康状况。通过从系统内各种来源（包括日志、指标和跟踪）收集、聚合和分析数据来实现可观察性。在本节中，我们将学习如何将 Jira 与日志记录和监控工具连接起来，以便将 Jira 问题与问题关联起来。

此操作步骤具有以下目标：

• 配置具有 Jira 实例的 Datadog 帐户

• 展示从 Datadog 创建的 Jira 问题

准备工作

要执行此操作步骤，您需要以下内容：

• 为了添加 GitLab 应用程序，需要 Jira 管理权限。

• 一个 Datadog 帐户

如何操作...

为了实现 Datadog 集成，我们需要执行以下步骤：

1. 在 Datadog 中安装 Jira 集成。

2. 从 Jira 创建 Datadog 的应用链接。

3. 连接 Jira 实例。

4. 在 Jira 中创建一个 Webhook（如果使用 Datadog 案例管理）。

5. 在 Datadog 案例管理中添加一个项目。

6. 创建一个案例并查看相应的 Jira 问题。

那么，Jira 是否有 Datadog 应用？

尽管 Jira 市场中会显示可用的列表，但 Datadog 并没有一个可以安装到 Jira 的应用。让我们使用以下步骤来查找并安装它：

1. 导航到 datadog。

2. 点击 Datadog Jira 集成 选项。

图 10.17 – Datadog Jira 集成

1. Datadog 概览 页面将显示。点击 获取应用。

图 10.18 – Datadog 概览页面

这将弹出一个窗口，表示集成配置需要在 Datadog 端完成。

图 10.19 – 集成配置开始于 Datadog

现在，为了配置 Datadog 集成到 Jira，您需要从您的 Datadog 帐户开始操作。

在 Datadog 中安装 Jira 集成

我们将通过以下步骤在 Datadog 中安装 Jira 集成：

1. 切换到您的 Datadog 帐户，选择左侧菜单中的 集成 选项。这将带您进入 集成 页面。

2. 在搜索框中输入 jira 并按 回车。Jira 集成图块将显示。

3. 选择 Jira 集成图块。

图 10.20 – Datadog Jira 集成图块

1. 会弹出一个 Jira 集成 窗口，选择 配置 标签。

图 10.21 – Jira 集成配置

配置页面将显示，您可以在此配置新的 Jira 帐户。根据说明，您需要在 Jira 中创建一个 Datadog 的应用链接。集成链接所需的一项内容是提供的公钥。请复制此密钥并保存到剪贴板。

图 10.22 – Jira 集成帐户信息

1. 切换到您的 Jira 实例，我们现在需要导航到 产品 菜单并添加一个应用链接。点击右上角的齿轮图标，然后点击 产品。

图 10.23 – Jira 产品选择

1. 在 产品 页面，向下滚动左侧菜单面板并选择 应用链接。

图 10.24 – Jira 应用链接

1. 现在我们可以通过选择创建链接来添加新的应用链接。

图 10.25 – 创建应用链接

1. 现在我们可以开始配置 Datadog 应用链接：

   1. 选择 app.datadoghq.com。

   2. 选择继续。

图 10.26 – 应用链接配置

1. 忽略配置应用 URL的警告，然后点击继续按钮。

图 10.27 – 应用 URL 配置

1. 对于应用链接，继续填写以下内容：

   1. DataDog。

   2. 对于应用类型，选择通用应用。

   3. 勾选创建传入链接框。

   4. 点击继续。

图 10.28 – 应用链接配置所需的详细信息

1. 在配置过程的最后部分，填写以下内容：

   1. datadog-jira)。你需要使用此值完成 Datadog Jira 集成。

   2. Datadog。

   3. 对于公钥，将从 Datadog Jira 配置步骤中复制到剪贴板的公钥粘贴进来。

   4. 点击继续。

图 10.29 – 完成应用链接配置

新的 Datadog 应用链接将显示并准备好使用。

图 10.30 – 应用链接已创建

1. 切换回 Datadog 应用以继续 Jira 集成配置。我们现在需要添加 Jira 中为 Datadog 应用链接创建的 Jira Cloud URL 和消费者密钥。然后选择连接。

图 10.31 – Datadog Jira 连接

重要提示

现在 Jira 实例已经连接，我们将有机会为 Datadog 案例管理设置一个双向集成的 webhook，以及一个从警报创建 Jira 问题的任务模板。在这个示例中，我们将配置Datadog 案例管理选项。

1. 你需要将提供的 webhook URL 复制到剪贴板。

图 10.32 – Datadog 案例管理 webhook 配置

1. 切换回 Jira 并导航到系统 | WebHooks。

图 10.33 – Jira WebHooks

1. 选择Datadog Webhook。

2. 将状态设置为启用。

3. 对于URL，输入从 Datadog Jira 配置步骤中复制到剪贴板的 webhook URL。

图 10.34 – Jira WebHook 配置

1. 在与问题相关的事件下，指定你想要与 Datadog webhook 关联的项目。

2. 对于问题，勾选创建、更新和删除框。

3. 在项目相关事件下，勾选删除框。

4. 点击保存按钮。

图 10.35 – Jira WebHook 配置（更多详细信息）

1. 在 Jira 中创建了 webhook 后，切换回 Datadog 应用程序。进入案件管理模块，并为 Jira 添加一个新项目集成。

2. 对于项目的 Jira 集成，请确保设置以下参数：

   1. 已为此项目启用 Jira。

   2. 在Jira (Atlassian) 账户下，输入您的 Jira Cloud URL。

   3. 将Jira 项目名称设置为与此 Datadog 案件管理项目关联的 Jira 项目。

   4. 输入要在 Jira 中创建的案件管理项目的问题类型。

   5. 启用自动创建并同步****Jira 问题。

   6. 配置您所需的同步选项以同步缺陷字段。

图 10.36 – Datadog 案件管理项目 Jira 集成

重要提示

现在我们可以测试 Datadog 集成。我们应该能够将新的案件事件添加到我们的 Datadog 项目中，这将自动创建一个关联的 Jira 问题。

1. 进入您的 Datadog 案件管理项目，选择新建 案件按钮。

图 10.37 – 创建新案件

1. 将显示一个新案件弹出窗口。填写标题字段，在描述下添加描述，最后点击创建 案件按钮。

图 10.38 – 创建案件参数

在 Datadog 中将创建一个状态为OPEN的新案件。我们还可以看到一个Jira Issue按钮。这表明一个 Jira 问题已被创建并链接回此 Datadog 案件。点击Jira Issue按钮查看关联的 Jira 问题。

图 10.39 – 显示带有 Jira Issue 按钮的新案件

我们可以在Web 链接部分看到与 Datadog 案件关联的 Jira 问题。

图 10.40 – Datadog 创建的 Jira 问题

我们现在已经成功将 Datadog 警报监控与 Jira 应用程序集成。警报现在可以自动创建 Jira 问题，并为整个 DevOps 过程添加有价值的见解。

第十一章：通过 Compass 中的 CheckOps 监控组件活动和指标

Compass 使你和你的团队能够理解你的软件如何协同工作。在分布式软件架构（微服务）中，有许多组件共同作用，构建出对客户有价值的东西。追踪这些组件，并理解它们的所有权和如何集成，可能是一项具有挑战性的任务。Compass 让软件团队轻松地对其组件进行目录管理，并能够直观地监控这些组件并提取有用的指标。

首先，我们将设置 Compass，这是一款独立的 Atlassian 产品，能够与其他 Atlassian DevOps 工具集成。一旦 Compass 可用，你将创建组件、管理团队、创建软件组件视图，并创建指标，帮助你的团队理解他们的软件组件如何结合在一起。

本章包含以下食谱：

• 配置 Compass

• 使用 CSV 文件导入分布式架构组件

• 将 Compass 与 Bitbucket Cloud 集成

• 在 Compass 中理解作为代码的配置

• 使用 Compass 创建开发平台

• 使用 Compass 测量 DevOps 健康状况

• 在 Compass 中使用模板

• 在 Compass 中实施开发者 CheckOps

技术要求

你将需要以下内容：

• Jira

• 一个包含你团队组件的 Git 仓库

• Bitbucket Cloud

配置 Compass

Compass 是一个独立的 Atlassian 产品，你需要单独购买。在配置 Compass 之前，你需要确保你的公司已订阅有效的 Compass 产品。

准备工作

首先，我们需要通过以下步骤准备好设置：

1. 访问 (www.atlassian.com/try/cloud/signup?bundle=compass)。

   到达后，你需要使用 Google 邮箱、工作邮箱或任何其他邮箱登录，点击使用邮箱注册。

提示

如果你曾经使用过任何其他 Atlassian 产品，如 Jira、Confluence 或 Bitbucket，建议你使用与这些产品相同的账户/ID 登录。理想情况下，你应该使用在前几章中一直使用的相同 Atlassian ID。

图 11.1 – Atlassian 登录界面

1. 登录你的 Atlassian ID 后，你将选择想要添加 Compass 的站点。你需要同意 Atlassian Cloud 服务条款和隐私政策。

重要提示

使用本书中的所有示例，你只需要免费计划。无需信用卡，如果你有三个或更少的用户，你将不需要为 Compass 付费。你将错过一些仅限付费套餐的功能，但你仍然可以仅使用免费版来跟随本书的内容。

1. 点击开始使用以开始配置 Compass。

图 11.2 – Compass 免费计划

几分钟后，Atlassian 的机器人将部署你自己的 Compass 实例，你将能够开始创建你的组件和团队。

如何操作……

在 Compass 成为你团队的有用工具之前，你需要为它添加组件。这些组件将跟踪构成你软件堆栈的各种元素。组件可以是库、服务、应用程序、依赖关系，或任何从软件角度来看，产品所需的东西。在本章的结尾部分，我们提供了一份食谱（使用 Compass 创建开发平台），讲解了 Jira 和 Compass 如何连接，并在 Jira 中显示 Compass 组件。这一切都由 Atlassian 自动化完成，如果你的组件存在于 Compass 中，它们将自动在 Jira 中显示。

将组件输入到 Compass 中有两种不同的方法。你可以手动创建它们，正如我们在本节中所做的那样，或者你可以导入它们。我们将在下一节讨论导入组件。现在，让我们以手动方式创建一些组件。

按照以下说明配置 Compass 中的组件目录：

1. 在 Compass 顶部的导航栏上，点击 创建 按钮。这将为你提供在 Compass 中创建各种不同元素的选项。在这第一步中，我们要选择 组件。

图 11.3 – 手动创建新组件

重要提示

创建组件有时是一门艺术。你可以选择 Compass 内置的多种类型。你需要选择最能描述你正在创建的组件的类型。如本节开头所述，组件是你软件构成的一部分。由于软件本身很复杂，它由许多不同的组件组成。在这里，你需要做好充分的准备，捕捉那些恰如其分地描述你软件的组件。

1. 一旦点击 组件，你将被提示选择你想要创建的组件类型。根据你的选择，从以下可用选项中选择：

   • 服务 – 独立可部署的软件单元，通常由个人或团队运营

   • 库 – 一组可重用的对象、函数和方法

   • 应用程序 – 完整的应用程序，如移动应用、桌面应用或命令行工具

   • 能力 – 一个更高级的产品功能，最终用户能够理解并看到其价值

   • 云资源 – 云服务商提供的实体或服务，具备消费者管理配置和监控功能

   • 数据管道 – 一系列工具和流程，将数据从源系统传输到目标系统

   • 机器学习模型 – 一种识别数据集中的模式并对其进行预测的算法

   • UI 元素 – 设计系统中的可重用构建块，组合起来创建模式和用户体验

   • 网站 – 一个或多个网页，位于一个域名下，主要由只读内容组成

   • 其他 – 描述为其他的通用软件组件

   以下截图显示了部分列出的选项：

图 11.4 – 可用的组件类型

重要提示

如你所见，针对软件的各个部分都有选项。选择最能代表你正在捕获的组件的类型。在刚开始时，这可能会有些挑战，因为你可能没有捕获到所有信息。这是一个好问题，因为拥有一个健康的软件产品需要团队对所有软件组件如何结合有 100% 的映射。捕获组件的空白可能会在软件产品的生命周期后期造成盲点，产生不利影响。

1. 一旦选择了组件类型，就该为其命名了。

图 11.5 – 为新组件命名

重要提示

在你有了合适的名称后，就该为组件指定一个所有者了。进行此活动时，最重要的一点是，每个组件都应该有一个人或团队来负责。这个字段不是必填的，但强烈建议填写。让一个团队负责一个组件将使其拥有该组件的所有权。他们将负责全面了解自己的组件。当发现错误时，你会希望知道谁负责该组件。如果一个组件没有指定任何所有者，也没关系，你可以跳过这部分，但强烈建议你开始为组件指定所有者。

1. 选择该组件的所有者团队。

图 11.6 – 新组件的所有者

由于这是我们的第一个组件，我们可能还没有团队，因此目前可以跳过这部分。等我们在后续部分创建团队后，可以编辑现有组件并将其分配给适当的团队。或者，你可以跳到还有更多……部分并在继续之前创建一个团队。

重要提示

如果你或其他人已经在 Jira 或 Confluence 中创建了团队，这些团队将在 Compass 中显示，并可以在此处选择。

1. 你可以提供的最后一条信息是一个指向代码库的链接。

图 11.7 – 添加组件源代码的信息

提示

这一步是可选的，但建议提供链接，以便充分利用 Compass 的功能。

1. 输入新组件信息后，是时候点击创建按钮了：

图 11.8 – 确认创建新组件的按钮

1. 如果您此时希望创建另一个组件，也可以点击创建另一个组件复选框。这将保留组件类型和拥有团队，但名称和仓库字段将清空，供您创建下一个组件使用。

   创建了第一个组件后，可以继续添加其余的组件。如果您想查看到目前为止创建的所有组件，只需点击导航栏中的组件按钮，您将被重定向到组件页面。

图 11.9 – 确认新创建的组件

您已经正式在 Compass 中创建了第一个组件！在下一部分中，我们将创建一个团队。

还有更多……

一旦您创建了第一个组件，就需要一个团队来继续首次配置 Compass。在上一部分中，如果您没有现成的团队，可能会跳过为组件添加团队。让我们看看如何在 Compass 中创建您的第一个团队：

1. 在 Compass 顶部的导航栏中，点击团队按钮。如果您点击下拉箭头，这将提示您邀请人员加入 Compass 或给您创建团队的选项；您还可以搜索现有的团队。

图 11.10 – Compass 中的团队门户

重要提示

邀请人员加入 Compass 需要许可证。如果您点击该按钮，电子邮件将发送给收件人，但在您的 Atlassian 管理员为该用户授予许可证之前，他们将无法访问 Compass。如果您是 Atlassian 管理员，您将能够授予许可证，但很可能您并不是 Atlassian 管理员，因此此操作直到您的 Atlassian 管理员自行添加用户后才会生效。

1. 假设您的团队成员已经拥有 Compass 许可证，请点击创建团队。这将显示一个窗口，您可以在其中创建团队并添加成员。

图 11.11 – 创建新团队

1. 您首先要做的事情是为您的团队命名。这可以是任何您想要的名称，但应该是具有描述性的，能让其他人一眼看出团队名称的含义。

   一旦您有了团队名称，就需要添加人员。您一次最多可以添加 50 人。

2. 接下来，您可以授予其他人加入您的团队的权限，无需您批准。这不是一个好的做法，是否启用此选项完全取决于您。

3. 最后，点击 创建团队 按钮，或者如果你不再想创建团队，点击 取消。

4. 创建团队后，它将出现在 Compass 的 团队 部分。你可以通过点击导航栏上的 团队 按钮进入 团队 部分。

图 11.12 – 审查新创建的团队

在 团队 页面，你还可以邀请成员并创建其他团队。

重要提示

你刚创建的团队不仅仅用于 Compass。这个团队在其他 Atlassian 产品中也可用，例如 Jira 和 Confluence。类似地，如果你或其他人在 Jira 或 Confluence 中创建了团队，那么你也应该能在 Compass 中看到这些团队。

使用 CSV 文件导入分布式架构组件

本教程介绍了如何通过 CSV 文件快速导入多个组件。这比手动创建组件要好得多，因为大多数团队需要跟踪的组件数量通常有几十个甚至上百个。

准备工作

手动导入每个组件将花费很长时间。幸运的是，你可以通过 CSV 文件导入组件。最少，你的 CSV 文件将需要两列重要信息。

所需数据如下：

列名称	必需输入
名称	你想要的任何名称
类型	SERVICE、LIBRARY、APPLICATION、CAPABILITY、CLOUD_RESOURCE、DATA_PIPELINE、MACHINE_LEARNING_MODEL、UI_ELEMENT、WEBSITE、OTHER

表格 11.1 – 必需数据

你还可以在导入时包含许多其他字段/列，但它们不是必需的。

以下是包含可选字段/列名称的列表：

生命周期阶段	预发布、活动中、已弃用
层级	1, 2, 3, 4
描述	组件的描述
标签	任何有助于对组件进行分类的附加信息
负责人团队	任何你想要的团队，按照下一节的特别指导进行设置
仓库	组件所在的仓库
聊天频道	任何可能涉及该组件的聊天频道信息
项目	引用/使用该组件的 Jira 项目
文档	组件的 Confluence 文档
仪表盘	链接到任何引用该组件的仪表盘
值班时间表	链接到任何负责该组件的团队的值班时间表
其他链接	任何你想要的内容
自定义字段	任何你想要的内容，但必须以 custom: 开头

表格 11.2 – 可选 CSV 字段/列

CSV 文件最重要的是确保表头行正确。表头行中的每个值应对应前述字段之一。请记住，表头行中的所有值应为小写字母，如下图所示：

图 11.13 – 表头列示例

知道了前置条件后，我们进入实际操作部分。

如何操作…

由于我们将把组件分配给一个所有者团队，所以在继续之前我们需要先获取该团队的 ID。我们将按照以下步骤进行操作：

1. 在 Compass 中，点击 团队 按钮并选择您想要的团队。

2. 选择团队后，您将被重定向到该团队的页面，您可以点击 … 获取所有者 ID。点击 复制 所有者 ID。

图 11.14 – 选择团队以获取所有者 ID

1. 拿到所有者 ID 后，是时候开始填写我们的 CSV 文件了。

图 11.15 – 填写包含所有者 ID 的 CSV 文件

1. 在捕获完所有组件后，将文件保存为 CSV 格式。请记住，每个文件最多只能导入 500 个组件。如果组件数量超过 500 个，您将需要将 CSV 文件拆分成多个文件。

图 11.16 – 保存 CSV 文件

1. 在 Compass 中，点击 创建 按钮并选择 导入组件。

图 11.17 – 导入组件

1. 当下一个窗口出现时，滚动到底部并点击 导入 按钮，位于 CSV 文件 选项的右侧。

图 11.18 – 导入 CSV 文件

1. 将您的文件拖动到 上传 区域以进行上传。

图 11.19 – 上传 CSV 文件

1. 如果您的 CSV 文件格式不正确，审核将无法通过。在这种情况下，建议您从前一屏幕下载示例 CSV 文件。如果所有检查标记为绿色，那么您可以点击蓝色的审核按钮，继续进行下一步。

图 11.20 – CSV 文件验证

1. 审核 步骤将分析您的文件并确定将导入多少个组件。点击蓝色的 创建 按钮继续。

图 11.21 – 审核组件

1. Compass 将花费几秒钟时间导入您的组件，导入完成后，您将能够查看新创建的组件。

   点击 查看组件，您将能看到所有组件并验证信息是否正确导入。

图 11.22 – 验证 Compass 中的组件

现在你的组件已经全部导入到 Compass，是时候学习如何创建更具动态性的组件了。

将 Compass 与 Bitbucket Cloud 集成

使用 Compass 的其中一个优点是它可以与 Bitbucket Cloud 连接。这个连接将允许 Compass 与 Bitbucket 进行通信，并将 Bitbucket 作为组件数据的单一可信来源。你需要有一个现有的 Bitbucket 仓库，用于与 Compass 集成。

如何操作…

在 Compass 中，你将通过以下步骤建立 Git 仓库与 Compass 之间的连接：

1. 在 Compass 中，点击导航栏上的应用程序。这将打开一个屏幕，显示所有可以与 Compass 集成的应用程序。通过点击Bitbucket 磁贴中的安装来选择 Bitbucket。

图 11.23 – 选择 Bitbucket 磁贴

1. 安装应该只需要几秒钟。安装完成后，Bitbucket 磁贴现在会允许你配置（或卸载）。点击配置按钮。

图 11.24 – 点击“配置”按钮

1. 在配置屏幕上，点击连接 到 Bitbucket。

图 11.25 – 连接到 Bitbucket

1. 当弹出窗口出现时，点击黄色的继续按钮。

图 11.26 – Bitbucket 授权

1. 在接下来的屏幕上，选择你要连接的 Bitbucket 工作空间，然后点击授予访问权限。

图 11.27 – 授予 Bitbucket 访问 Compass 的权限

1. 一旦你的工作空间已连接，接下来需要选择一个仓库，用于存放你的组件数据。点击蓝色的选择 仓库按钮。

图 11.28 – 选择 Bitbucket 仓库

Compass 将显示你工作空间中可用的仓库，你只需要选择它们。选择仓库中的组件类型，然后点击蓝色的选择按钮。

图 11.29 – 选择 Bitbucket 仓库

1. 选择在导入过程中为所有仓库设置配置文件的复选框。

图 11.30 – 导入过程中设置配置文件

这将把 compass.yml 文件添加到每个仓库中，这对于 Compass 使用 Bitbucket 作为组件元数据的唯一可信来源至关重要。一旦做出选择，您将看到以下屏幕，随后会提示您开始导入过程：

图 11.31 – 开始 Bitbucket 导入过程

1. 点击蓝色的 开始导入 按钮，您将收到 导入完成 的通知。

2. 当您完成将 Bitbucket 与 Compass 连接时，点击 完成。

您已成功将 Bitbucket Cloud 与 Compass 集成。

理解 Compass 中的配置即代码

在之前的两个步骤（配置 Compass 和 使用 CSV 文件导入分布式架构组件）中，您已经了解了如何手动创建和导入组件。这两种方法都需要大量的用户输入，并且容易出错。而且，如果您的仓库中的组件数据发生变化，就需要有人进入 Compass 手动更新组件数据。更好的方法是让代码库中的代码自动更新组件信息。这可以通过利用 配置即代码（CaC）来实现。

一旦将您的 Bitbucket 仓库与 Compass 连接，您就能够为每个组件使用一个特殊的 YAML 文件。此 YAML 文件存在于您的代码仓库中的每个组件内，最棒的是，它是版本控制的。您无需手动更新 Compass 或通过 CSV 文件更新，只需在代码仓库中管理所有组件数据，Compass 将处理其余部分。

如何操作…

在您的代码仓库中，找到 compass.yml 文件。您将在此提供组件元数据，这将使该组件成为 Compass 中的一个受管理组件，基本上意味着数据将来自 .yml 文件，而非手动来自 Compass。

以下示例将针对在 Bitbucket 仓库中使用 compass.yml 文件跟踪的单个组件。每个组件需要自己的 compass.yml 文件。确保每个独特组件的 compass.yml 文件位于代码仓库中的各自子文件夹内。我们可以按照以下步骤进行操作：

1. 在您的代码仓库中，找到或创建 compass.yml 文件。以下是当 Bitbucket 与 Compass 连接时创建的示例 compass.yml 文件。如果您还没有完成此连接，请跳至 将 Compass 与 Bitbucket 集成 Cloud 部分。

图 11.32 – compass.yml 示例

重要提示

你仍然需要在 Compass 中创建组件。一旦组件创建完成，你将能够获取该组件的唯一 ID，然后该 ID 将在 compass.yml 文件中用于管理组件的元数据。当你将仓库连接到 Compass 时，Bitbucket 会为你创建一个组件，但如果你想追踪/添加多个组件，你需要多个仓库，或者你可以手动在 Compass 中创建组件，然后在多个 compass.yml 文件中引用它们，按照需要将它们分布在你的仓库中。

在接下来的部分中，我们将首先分解并解释该文件的内容，然后将其提交到 Bitbucket，之后将数据作为托管组件推送到 Compass。

1. id（必填项）：这是 Compass 用来跟踪你的组件的唯一标识符。通过点击 Compass 中组件目录中的组件并点击 复制 组件 ID 来获取该 ID。

图 11.33 – 获取组件 ID

1. name（必填项）：这将是你的组件名称。应该与你在 Compass 中的名称一致。

2. description（可选项）：这是你组件的描述。如果你想用多行来描述你的组件，你需要以文本 |- 开头。

3. ownerId（可选项）：如果你想将组件分配给某个团队，你需要从 Compass 中获取该值，找到应拥有该组件的团队，然后点击 复制 所有者 ID

图 11.34 – 将组件分配给团队

1. configVersion（可选项）：将其保留为 1，因为这是你唯一可以提供的值。

2. typeID（必填项）：这需要与可用的组件类型匹配：

   • APPLICATION

   • SERVICE

   • CAPABILITY

   • CLOUD_RESOURCE

   • DATA_PIPELINE

   • LIBRARY

   • MACHINE_LEARNING_MODEL

   • OTHER

   • UI_ELEMENT

   • WEBSITE

其余字段完全可选，如果你想填写它们，你可以阅读 Atlassian 的文档 (E)。

1. 一旦你更新了文件，所需要做的就是通过点击 提交 按钮在 Bitbucket 中提交你的更改。

图 11.35 – compass.yml 提交示例

你将看到你更改的详细信息。

图 11.36 – 提交示例

1. 接下来，创建一个拉取请求，将你的更改合并回 master 或 develop 分支。

图 11.37 – compass.yml 拉取请求示例

1. 使用你常规的拉取请求流程批准并合并拉取请求。

   返回到 Compass，对于你管理的组件，你将看到更新后的信息。

图 11.38 – Compass 中的组件确认

1. 最后，如果你在 Compass UI 中创建了组件，并且希望尽量减少创建compass.yml文件的工作量，请进入 Compass UI 中的该组件，选择左侧的Config-as-code。

图 11.39 – compass.yml 拉取请求示例

你将能够下载compass.yml文件，然后可以在你的 Bitbucket 仓库中使用该文件。

图 11.40 – 配置即代码示例

这最终是管理和追踪 Compass 中组件的最佳方式。由于 Compass 组件应该代表你代码中的子系统，因此将这个.yaml文件嵌入到你的代码库中是合理的。

现在你的所有组件都已添加到 Compass 中，是时候开始利用 Compass 来确保你的组件是最新的并且处于良好的工作状态了。

使用 Compass 创建开发者平台

Compass 旨在帮助你全面了解你的代码是如何相互连接的。利用 Compass 中的所有组件，现在是时候构建一个开发者平台了。这个平台将为你提供一个统一的视图，展示所有的组件、库、服务、应用程序和文档，以及你在 Compass 中追踪的任何内容的健康状况和状态。

如何操作…

我们首先要做的是连接相关的组件，并突出显示它们的依赖关系。这些依赖关系将显示一个特定组件所依赖的其他组件。在 Compass 中映射出这些关系对于理解你的软件架构至关重要。了解这些关系使得你的团队能够更好地理解组件如何彼此依赖，从而使你的软件能够正常工作。

让我们通过以下步骤来创建这些依赖关系：

1. 点击 Compass 头部的组件，然后选择你要添加依赖关系的组件。

图 11.41 – 从现有组件中选择

1. 在左侧，点击依赖项。

图 11.42 – 选定组件详情

1. 在Depends on的下拉框/字段中，选择你的选定组件所依赖的组件。

图 11.43 – 选择组件依赖

点击添加依赖，你将看到以下屏幕：

图 11.44 – 添加组件依赖

从这里开始，添加尽可能多的依赖关系，以便适当地映射出你的组件如何彼此连接。

重要提示

Compass 允许你以列表或地图视图查看你的依赖关系。这将帮助你可视化组件之间可能存在的循环依赖关系。另外，请记住，Compass 允许一个组件最多有 25 个依赖项。最多 100 个其他组件可以依赖于一个组件。

还有更多…

Compass 内建的功能允许你为 Compass 目录中的任何组件发布公告。这非常有用，因为团队可以及时了解与他们关心的组件相关的最新情况。

Compass 包含一个功能，让你为 Compass 目录中的任何组件创建公告。这对于保持团队了解重要组件更新非常有用。

要与团队分享有关特定组件的相关信息，请按照以下步骤在 Compass 中创建公告：

1. 选择一个组件，然后点击公告。

图 11.45 – 创建公告选择

1. 点击创建公告。

图 11.46 – 创建公告

1. 为你的公告提供一个名称和目标日期。可选地，你还可以提供一个描述。然后，点击创建。

图 11.47 – 公告创建示例

你的公告现在可以在该组件中查看。任何依赖于该组件的组件也将能够看到公告。此外，团队成员会收到电子邮件通知，并在 Compass 用户界面中看到通知徽章，提示有新的公告可用。

图 11.48 – 公告审核示例

另请参阅

这个方案有一些额外的元素，你应该考虑。

监控组件活动

活动页面将展示组件的当前状态。在活动页面中，你可以看到与选定组件相关的部署、事件、标记以及任何警报。这个视图会让你实时了解组件的状态。如果组件之间通过依赖关系相连接，你也可以看到这些信息。

图 11.49 – 组件活动监控

与 Jira 连接

Jira 也可以与 Compass 连接，你可以在 Jira 中可视化 Compass 的数据，反之亦然。曾经有两种不同的方式将 Compass 组件与 Jira 连接。其中一种是在 2022 年推出的。希望将 Compass 与 Jira 集成的用户需要在 Jira 中启用一个自定义字段，该字段会从 Compass 中提取组件。该字段和方法在 2024 年 5 月 31 日被弃用。因此，以下步骤是确保你的 Compass 组件可以在 Jira 中使用的最佳方法：

1. 转到你的 Jira 项目并点击组件（请注意，这只适用于公司管理的项目）。

图 11.50 – 从公司管理的 Jira 项目中选择组件

1. 进入组件部分后，你将看到 Jira 已自动与 Compass 连接。点击转到问题。

图 11.51 – Jira 和 Compass 连接时的组件菜单

1. 选择任意一个问题并点击组件字段。

图 11.52 – Jira 中的组件字段

1. 在下拉框/字段中，你现在将看到存在于 Compass 中的组件。

图 11.53 – Jira 中的 Compass 组件

将 Jira 与 Compass 连接可以让你的团队更加高效，最棒的是你无需重复输入数据。你无需在 Jira 中重新创建所有组件，而是可以在 Jira 中利用相同的 Compass 组件。如果使用仅限 Jira 的组件，你需要在 Compass 中重新创建这些组件。这将确保 Jira 拥有从 Compass 中提取的最新和最准确的组件。

使用 Compass 衡量 DevOps 健康状况

将组件与 Compass 连接并绘制其依赖关系是很棒的，但即使这样做了，也无法完全了解你组件的健康状况和状态。使用 Compass，你可以创建评分卡来帮助可视化组件的健康状况。

如何操作…

Compass 自带了一些评分卡。这些评分卡可能正是你所需要的，但如果你需要额外的评分卡，创建它们非常简单。按照以下步骤即可：

1. 在 Compass 中的导航栏中，点击健康。

图 11.54 – 健康按钮以进入评分卡

到达后，你将能够看到现有的评分卡。

图 11.55 – Compass 评分卡

1. 点击右上角的创建评分卡。

图 11.56 – Compass 菜单选项以创建评分卡

这将显示一个弹窗，允许你创建评分卡。

图 11.57 – 创建评分卡的弹窗

提供名称、描述和所有者，然后选择组件类型及评分卡的应用方式。点击下一步继续。

1. 在下一屏幕中，你将从组件中选择元数据，以帮助你构建标准，让团队评估组件的健康状况。

图 11.58 – 选择要在评分卡中显示的度量标准

1. 在构建评分卡时，你可以选择标准类型。你可以选择字段或度量标准。

图 11.59 – 选择你的标准类型

之后，你可以选择将用作标准的字段或度量标准。

1. 最后，你为标准选择权重。

提示

对于你要为评分卡创建的所有标准，重复步骤 4 和 5。所有标准的权重总和必须为 100%。完成后，评分卡将如下所示：

图 11.60 – 在创建评分卡前完成标准设置

1. 完成后点击创建。

   在你的组件中，你将能够看到评分卡已根据你配置的方式应用到该组件上。

图 11.61 – Compass 中的评分卡值

尝试所有可用的不同标准。构建这些评分卡是 Compass 与其他 Atlassian 产品的区别所在。当你的团队在代码中使用这些组件时，评分卡会跟踪关键度量，帮助你们了解代码的健康状况和状态。

在 Compass 中使用模板

模板在 Compass 中允许你创建代码模板，帮助简化软件开发流程。这些模板成为 Compass 中的组件，可以在整个软件堆栈中根据需要重复使用。如果你的团队经常需要创建相似的代码或配置，模板能帮助团队提高效率。通过使用模板，你团队的代码质量也能得到提升，因为你总是有一个坚实的基础来开始工作。这些你将学习如何创建的模板不必是组件；它们可以是团队经常依赖的任何有用代码片段。

如何操作…

使用模板的第一步是将 Compass 与 Bitbucket 连接。如果你尚未将 Bitbucket 与 Compass 连接，请参考将 Compass 与 Bitbucket Cloud 集成的步骤。

一旦你的仓库与 Compass 连接，接下来就是创建你的第一个模板。让我们按照以下步骤进行：

1. 在 Compass 的导航栏中，点击模板。

图 11.62 – Compass 中的模板

假设这是你第一次创建模板，你应该会看到一个蓝色按钮，提示你创建第一个模板。点击它。

图 11.63 – 在 Compass 中创建模板

1. 填写信息，这与手动创建新组件时的步骤完全相同。

图 11.64 – 模板创建信息

唯一的主要区别是，在创建模板时，你需要提供一个仓库的链接。这个仓库可以是你源代码仓库中的任何仓库，但它需要与 Compass 连接，这在最终的配方中进行配置。当你创建模板时，你的基础仓库将被分叉：

图 11.65 – 选择所有者和仓库链接

填写所有信息后，点击蓝色的下一步按钮。

图 11.66 – 完成模板创建信息

1. 可选地，你可以提供一个 Webhook。

图 11.67 – 添加可选的 Webhook 和参数

1. 审核你的新模板并点击创建。

图 11.68 – 审核模板信息

你新创建的模板现在将在你的组件目录中可用。

在 Compass 中实施开发者 CheckOps

CheckOps 是团队为评估其软件系统组件的健康状况和状态所执行的活动。建议至少每周进行一次 CheckOps，但具体频率由各个团队自行决定。至少，在每次软件开发冲刺结束时，应进行一次 CheckOps。通过 CheckOps，团队可以审查评分卡及其负责组件的整体健康状况。如果某个组件出现故障，团队可以通过每周的 CheckOps，找出解决方案，修复故障并使组件恢复到健康的评分卡状态。

定期进行 CheckOps 是个好主意，因为它使团队能够持续监控他们负责的组件的性能。很多时候，团队会将组件添加到 Compass 中，但却没有跟进组件的健康状况和状态。如果让组件滞后或服务/可靠性下降，可能会导致软件出现严重问题。每周进行 CheckOps 使团队能够持续审查关键指标，并根据需要进行调整，而不是等到软件发生灾难性故障时才进行处理。早期并经常处理组件问题，使得软件质量更高，下游问题更少。

执行每周的 CheckOps 非常简单直接。所有操作都在 Compass 应用程序中处理，每个团队可以根据分配给他们的组件进行自己的 CheckOps。如果组件没有分配给团队，建议检查组件目录，并为每个组件分配合适的团队。

接下来，我们将带你了解为进行第一次 CheckOps 准备的步骤。

如何操作…

请按照以下说明正确配置 Compass，以便你的团队能够进行每周的 CheckOps：

1. 在 Compass 导航栏中，进入团队部分：

图 11.69 – 从 Compass 导航中选择团队

1. 通过点击可用团队中的一个团队来选择你的团队。

图 11.70 – 从可用团队列表中选择一个团队

1. 选择你的团队后，在左侧导航中选择CheckOps。

图 11.71 – 选择团队后进行 CheckOps 的步骤

1. 由于这是你的第一次 CheckOps，你将能够点击蓝色的开始 CheckOps按钮。

图 11.72 – 在 Compass 中启动 CheckOps 的仪表板

1. 这将把你重定向到健康详情，你将在这里进行每周的 CheckOps，接下来的小节会介绍如何操作。

在你进行第一次 CheckOps 之前，有一些事情需要你考虑：

• 全面了解你的组件如何影响并受软件架构中其他元素的影响。

• 记录你在第一次进行 CheckOps 之前可能遇到的任何事件或异常。在准备每周进行 CheckOps 时，你需要每周记录这些内容。

• 理解你们组件的服务级目标。你的利益相关者对你们特定组件的期望是什么？你需要每周检查这些，以确保你的组件符合期望。

• 为你的团队确定一个每周的节奏。每周同一时间，你们团队应该聚在一起进行每周的 CheckOps。这应该类似于任何的迭代规划、每日站会、迭代回顾等。

现在，你已经选择了团队并启动了 CheckOps，是时候学习如何进行每周的 CheckOps 会议了。

还有更多内容……

还有很多内容需要涵盖，这一部分将详细说明你应该如何处理每周的 CheckOps 会议。

重要提示

当你们团队准备每周的 CheckOps 会议时，特别需要关注那些评分卡显示需要关注的组件。一旦获得了这些信息，并且你们已经进行了一些分析/调查，找出了根本原因，就可以进行每周的 CheckOps 了。

请按照以下步骤操作：

1. 在健康详情页面中，你需要专注于 Compass UI 中最右侧窗格的CheckOps部分。

图 11.73 – Compass 中的 CheckOps UI

1. 从情绪开始，讨论一下你们团队这一周的感觉如何？这应该是针对其组件的运营方面。组件是否按预期运行，还是自上次 CheckOps 以来遇到了多个问题？

   团队可以从可选的情绪中进行选择，包括以下几种：

   • 惊人

   • 好

   • 好的

   • 糟糕

   • 糟糕透了

图 11.74 – 团队情绪选择

1. 接下来，你们团队将一起填写三个不同的反思部分。这些反思问题与传统的迭代回顾非常相似。我们来讨论一下你们团队应该为每个部分提供什么样的信息。你将看到以下标签：

   1. 做得好的方面是什么？

      讨论一下上周你们的组件表现得特别好的方面。有时，这可能会让你觉得有些自夸，但记录下你们团队的胜利是非常重要的。这有助于建立声誉，并为团队提供所需的积极反馈，以保持正确的方向。突出表现特别好的组件。讨论所有顺利进行的积极事情，以及由于这些事情的顺利进行，团队或客户获得了什么。

图 11.75 – 做得好的问题

1. 有什么可以改进的地方？

   总是有改进的空间。在这个反思问题中，你的团队应着重识别那些可能做得不错但仍有改进空间的事项。更常见的情况是，你应捕捉团队遇到的小问题和挫折，尽管它们能迅速被修复或解决。这是一个发现组件中的困扰并想办法消除它们的好机会。没有任何想法是坏的，团队应该被鼓励提出改进意见。这通常需要团队之间有高度的信任和健康的团队环境，大家可以自由讨论意见。

图 11.76 – 什么可以做得更好？问题

1. 我们如何改进？

   最后的反思问题使你的团队能够真正思考如何改进。这类似于之前的反思问题，但这次要思考需要改进的任何方面。这些改进不必是技术性的，团队可能需要改进文档或依赖关系。你的团队应具有前瞻性，识别能更好支持组件的机会，同时寻找提高其负责组件质量的方法。

图 11.77 – 我们如何改进？问题

1. 每周 CheckOps 过程的最后一步是捕捉团队在接下来一到两周内需要采取的行动项目。这些行动项目应每周进行回顾，以确保团队正在积极推动这些项目的完成。在 CheckOps 过程中，团队应捕捉尽可能多的行动项目。与 Confluence 不同，在 Confluence 中你可以将行动项目分配给个人，而在这里，团队必须更加勤奋和负责，确保这些项目能够顺利完成。你也不能像在 Confluence 中那样为这些行动项目设置到期日期，这些行动项目也没有与 Jira 连接。

图 11.78 – 执行 CheckOps 后的行动项目

1. 完成所有信息捕捉后，你可以点击完成按钮。

2. 完成 CheckOps 后，你始终可以在团队的 CheckOps 仪表板中查看当前及之前的 CheckOps。你可以通过点击 Compass 中团队资料左侧导航栏的CheckOps来访问此页面。

图 11.79 – 审查之前的团队 CheckOps

1. 在此，你可以点击 CheckOps 日期旁的省略号来编辑你的 CheckOps。

图 11.80 – 编辑以前的 CheckOps

1. 你也可以在此视图中关闭你的行动项目。

图 11.81 – 完成先前的行动项

1. 最后，在你团队的概览页面上，任何在 CheckOps 会议中记录的未完成的行动项都会被展示，提醒你的团队，并希望能够激励他们去处理这些待办事项。

图 11.82 – CheckOps 一目了然的行动回顾

现在你已经知道如何进行每周的 CheckOps，在接下来的部分，我们将讨论一些最佳实践，确保你和你的团队能够充分利用每次 CheckOps 会议。

另见

执行每周 CheckOps 会议其实是一件简单的事，但有一些建议能够帮助提升每周 CheckOps 的有效性。这些就是CheckOps 最佳实践。遵循这些建议，你可以帮助团队最大化每周 CheckOps 给团队和公司带来的价值。

一致性

不要跳过每周的 CheckOps。有时候你的团队可能没有很多时间，或者有时评分卡上全是绿色。即使一切顺利，也要养成每周在相同时间进行 CheckOps 的习惯。如果有假期，确保安排在假期之前或之后进行。养成定期举行 CheckOps 会议的习惯，将确保你的团队把它视为高优先级任务。这样，遇到问题时，团队就能迅速调动肌肉记忆，知道如何进行 CheckOps 会议，而不是浪费时间琢磨会议流程，能够专注于解决关键问题。

评分卡

持续审查你的评分卡以及评分卡中的指标。评分卡是影响每周 CheckOps 讨论项目的关键指标之一。如果评分卡总是显示正面结果，但实际上软件层面有问题，那么就需要审查那些影响评分卡的项目。确保它们准确无误，并能够适当反映软件层面的情况。根据实际情况调整评分卡中的指标，确保你的组件健康状况能够反映最准确的数据。这将帮助你拥有最佳的每周 CheckOps，因为你将有最准确、最相关的数据来推动讨论、决策和任何需要采取的行动。

跟进

最终的建议是确保你的团队始终能够落实你的行动。如果忽视问题，技术债务会迅速积累。你不必立刻采取行动，但在每周的 CheckOps 会议中记录下来的每一个行动都应该在下次 CheckOps 会议前解决。未能采取行动只会导致糟糕的指标随着时间的推移变得更糟。执行并采取行动的一个额外好处是，团队会观察到这些行动正在得到解决。这将鼓励他们识别更多的低效和问题，并希望这些问题也能得到解决。

第十二章：使用 Opsgenie 警报进行升级

作为 Atlassian Open DevOps 套件的一部分，您还可以访问 Opsgenie。Opsgenie 是一款独立的产品，允许团队管理警报、事件和事件升级。它通常由使用 Jira Service Management 的代理使用，但它也适用于需要参与解决生产问题的软件团队。软件团队可以利用 Opsgenie 的强大功能，管理对已部署到生产环境中的系统发生的警报和事件。

当我们查看整个 DevOps 生命周期时，Opsgenie 促进了监控活动。一旦您的产品和服务在生产环境中部署，监控和响应事件是反馈环路中的关键部分。本章将探讨如何配置 Opsgenie 并将其与 Jira 集成。

本章包含以下内容：

• 设置 Opsgenie 团队

• 将 Opsgenie 与 Jira 配置

• 设置值班计划

• 配置升级政策和规则

• 升级和通知配置

• 通过 ChatOps 改善团队沟通和响应

技术要求

您将需要以下软件：

• Jira

• Opsgenie

• Compass

设置 Opsgenie 团队

在这个步骤中，我们将配置您的团队，使得 Opsgenie 在事件发生时可以发送适当的通知。如果您已经在 Jira、Confluence 或 Compass 中创建了团队，您需要在 Opsgenie 中重新创建您的团队，因为截至目前，Opsgenie 中的团队与其他工具中的团队设置无法互通。如果您希望团队名称和成员相同，您需要在 Opsgenie 中精确地重新创建该团队。否则，您可以选择在 Opsgenie 中创建一个全新的团队。

如何操作

以下步骤将指导您如何在 Opsgenie 中创建团队：

1. 在 Opsgenie 中，点击导航栏中的 团队。

图 12.1 – 在 Opsgenie 中选择团队

1. 点击 添加团队。

图 12.2 – 添加新团队

1. 提供您的团队名称和描述，如果您有成员信息，请将成员的姓名也添加进去。添加完成员后，点击 添加团队 完成新团队的创建。

图 12.3 – 新团队详情

重要提示

如果您的团队成员未显示，则需要前往 Opsgenie 的设置页面，在导航栏中添加用户。如前所述，Opsgenie 独立于其他 Atlassian 工具，用户也是独立管理的。

1. 如果您尚未将团队成员添加到 Opsgenie，可以通过点击左侧面板中的 成员，然后在 成员 页面顶部点击 添加成员 来添加成员。

图 12.4 – Opsgenie 设置以添加新成员

将任何缺失的团队成员添加到你的 Opsgenie 团队，并分配适当的角色（用户或管理员）。添加完成员后，点击添加。

图 12.5 – 将成员添加到团队并分配适当角色

现在你的团队已经在 Opsgenie 中完成了入驻。接下来是创建团队的值班时间表，这将在下一个部分中介绍。

使用 Jira 设置 Opsgenie

Opsgenie 是一个独立的 Atlassian 产品，通常与 Jira 服务管理一起捆绑，或在使用 Atlassian 的 Open DevOps 包时提供。当你注册这两项服务中的任意一项时，Opsgenie 会被启用，但直接进入 Opsgenie 产品并不容易。对于本章节，我们将重点讲解如何通过 Jira 使用 Opsgenie。由于 Open DevOps 不包括 Jira 服务管理，因此本章节不会讨论 Jira 服务管理，但欢迎你探索 Jira 服务管理的功能，它是一个非常适合 IT 服务管理团队使用的优秀产品。

如何操作

在 Jira 中，选择你的团队用于跟踪开发任务的 Jira 项目。进入该项目后，你首先需要启用并连接 Opsgenie。你需要按照以下步骤操作：

1. 选择你希望与 Opsgenie 集成的 Jira 项目，然后进入项目设置并选择工具链。

图 12.6 – 从 Jira 项目中选择工具链

1. 在工具链窗口中，点击添加。从下拉菜单中选择添加 值班团队。

图 12.7 – 从工具链中添加新的值班团队

1. 选择Opsgenie并点击添加 到项目。

图 12.8 – 选择 Opsgenie 作为值班团队提供者

1. 创建或搜索一个团队。

图 12.9 – 添加一个值班团队

1. 输入你的团队名称并点击绿色圆圈以创建团队。

图 12.10 – 选择要添加的团队

1. 点击添加 团队按钮。

图 12.11 – 添加一个值班团队

1. 返回到你的 Jira 项目设置，点击功能。

图 12.12 – 从 Jira 项目中选择功能

1. 在操作下，找到值班部分，并确保滑块是绿色的。

图 12.13 – 从 Jira 项目功能中启用值班

现在，您应该能够访问您的值班安排，并且可以从您的主要 Jira 项目中跳转到 Opsgenie。在您的 Jira 项目中，您将看到一个值班部分和一个写着在 Opsgenie 中查看的链接。

图 12.14 – 从 Jira 项目中查看值班视图

现在，Opsgenie 已与 Jira 连接，您的团队已准备好开始在 Jira 中管理警报并查看值班安排。

设置值班安排

一旦您的团队创建完成，并且团队成员已被添加，就可以添加值班安排了。值班安排可以让您的团队分担责任，确保您的组件和软件始终有覆盖。如果生产环境出现问题，值班安排将根据事件发生的时间和分配到该时间段的团队成员，知道通知谁。

如何操作

Opsgenie 中的值班安排让您的团队保持组织性，并分配管理和确保关键组件正常运行的责任。以下步骤将向您展示如何配置团队的值班安排：

1. 在 Opsgenie 中，点击导航栏中的团队，然后点击您想为其创建值班安排的团队。

图 12.15 – 选择 Opsgenie 团队

1. 一旦进入团队仪表板，点击值班按钮。此时，您将看到几个不同的选项。现在，向下滚动，找到值班部分。

图 12.16 – 团队值班安排

重要提示

轮班决定了在特定时间段内，您的团队中谁将值班。应该已经可以看到一个现有的轮班。我们将编辑这个现有的轮班。您还可以选择创建额外的轮班。添加新轮班可能会使事情变得复杂，因此建议在您的团队熟悉值班时，保持单一轮班。大多数软件团队不习惯值班，所以这可能会有一些学习曲线。尽量在团队开始时保持轮班简单。随着您的团队变得更加熟练和适应轮班，Opsgenie 将能够随您的团队一起扩展和成长。作为最佳实践，建议将至少一周的完整时间分配给每个团队成员作为其轮班的一部分。

1. 点击轮班标题下的铅笔图标按钮，编辑现有的轮班。

图 12.17 – 编辑现有值班轮班

1. 首先，将轮班名称更改为更符合您和您的团队需求的名称。

图 12.18 – 编辑轮班名称

1. 在此，点击参与者，会出现一个搜索框。在这里，输入团队成员的名字，将他们添加为该轮班的参与者。

图 12.19 – 将团队成员添加为参与者

1. 接下来，设置您的轮班类型选项。如前所述，建议您设置每周轮班。您可以选择每日、每周或自定义轮班。

图 12.20 – 选择轮班类型

1. 之后，您将设置轮班的开始日期。您还可以选择设置轮班结束时间。大多数团队的轮班会是长期的，几乎没有结束日期。

图 12.21 – 选择轮班开始日期

1. 填写完所有信息后，Opsgenie 将创建您的值班计划：

图 12.22 – 更新后的轮班值班计划

点击添加按钮，您的值班计划将被设置。

重要提示

在这一点上，您可以为周末、节假日以及预定的休假日设置额外的值班计划。无论您的团队需要什么，Opsgenie 都足够灵活，您可以将团队的计划输入到 Opsgenie 中，以确保下一步的升级策略和路由规则能够有效工作。

您的值班计划现已创建。每当轮到某人值班时，他们会收到 Opsgenie 的通知，开始轮班。

配置升级策略和规则

一旦您的值班计划配置完成，就该配置升级策略和路由规则了。Opsgenie 使用来自上一步的升级策略、路由规则和值班计划来确定在发生事件时，谁会收到通知。

重要提示

正确配置升级策略和路由规则非常重要，否则您可能会把警报发送给错误的团队。您配置的升级策略将决定发生警报时哪些用户会收到通知。最重要的是，升级策略决定了用户接收到通知的顺序和时间，依据警报创建后的时间间隔。如果您的团队没有回复，链条中的下一个人会收到通知，直到有人采取行动解决警报/事件。路由策略将决定警报发生时通知如何传递。您有一些不同的选项，接下来的步骤将详细探讨这些选项。

如何操作

默认情况下，您应该已经在 Opsgenie 中创建了一个升级策略。与创建值班计划类似，您可以选择修改现有的升级策略，或者添加额外的升级策略。

升级策略决定了当出现问题时，Opsgenie 中谁会收到警报通知。让我们配置你的第一个升级策略：

1. 从 Opsgenie 中选择你的团队。

图 12.23 – 选择的团队来配置升级策略

1. 首先，将鼠标悬停在现有的升级策略上，你将看到编辑按钮显示出来。

图 12.24 – 编辑现有升级策略

点击编辑按钮将弹出一个菜单，允许你配置升级策略。

图 12.25 – 可以配置的升级策略

1. 第一个需要更改的项是升级。可以随意更改为你想要的内容。

图 12.26 – 更新后的升级名称

1. 接下来，你可以选择性地提供一个描述文本，帮助你的团队更好地理解这个特定升级策略的目的。

图 12.27 – 更新后的升级描述

1. 最后，你可以修改现有规则或添加额外规则。

图 12.28 – 更新后的升级规则

重要提示

默认情况下，一旦创建警报并且未立即确认，升级策略将立即通知你的值班人员。然后，如果在 10 分钟内，值班人员未确认该警报，将向团队中的所有成员发送通知。包括所有当前不在值班轮换中的成员。

1. 如果你需要进一步升级，可以添加额外的规则。

图 12.29 – 额外的升级规则

1. 在添加额外规则时，首先需要确定当警报未被确认或未关闭时，升级策略是否会进行升级。

图 12.30 – 确定规则何时触发

1. 一旦做出决定，接下来选择警报创建后能经过多少时间。

图 12.31 – 确定触发警报后应等待多长时间

1. 接下来，选择谁将接收到升级通知。你有很多选择，只要记住，随着时间的推移，你需要将警报的可见性提高到适当的人员，以便他们能够采取行动解决警报。

图 12.32 – 选择谁应收到警报通知

1. 最后，选择一个特定的团队或用户来接收通知。可用的团队将由前一个步骤决定。

图 12.33 – 选择接收警报的团队

1. 完成升级规则设置后，点击保存。

图 12.34 – 保存升级规则

还有更多内容

既然升级策略已经存在，现在是时候处理路由规则了。

路由规则

与升级策略类似，每个团队应该都有一个默认的路由规则。路由规则非常简单，你可以修改现有的路由规则，或者完全添加一个新的路由规则。以下是步骤：

1. 返回到 Opsgenie，在值班部分，我们将修改默认的路由规则。

图 12.35 – 路由规则配置

重要说明

设置路由规则时，你有三个主要选择。你可以选择不路由警报、将其路由到升级策略，或者直接将其路由到你的值班团队。

1. 点击现有的路由规则，然后你将能够选择要将警报路由到哪种类型的路径。以下截图展示了可用的选项。

图 12.36 – 选择升级路由规则

1. 或者，如果你不想使用 Opsgenie 提供的默认规则，你可以创建一个新的路由规则。与创建升级规则相比，创建路由规则时会有更多选择。以下步骤将说明如何配置路由规则：

   1. 要开始，点击右上角的添加路由规则。

图 12.37 – 添加新路由规则

1. 点击添加路由规则按钮后，系统会提示你为路由规则提供一个名称。

图 12.38 – 为路由规则提供名称

1. 接下来，你需要选择路由规则何时生效。你可以选择匹配所有警报，这意味着对于任何警报，路由规则都会生效（默认设置）。另外，你还可以根据警报的条件来触发路由规则。

图 12.39 – 选择触发路由规则的条件

1. 你可以根据警报的优先级或与警报相关的标签创建条件。最重要的一点是，你可以让路由规则在接收到特定优先级的警报时生效。

图 12.40 – 确定路由规则的条件

1. 一旦设置好条件，最后一步就是确定由自动化规则触发的操作。

图 12.41 – 确定路由规则将采取的操作

1. 一旦选择路由，只需点击Add按钮完成创建新的路由规则。

图 12.42 – 添加新的路由规则

现在你的升级和路由规则已经配置好，是时候管理从 Opsgenie 发送的通知了。

升级和通知配置

当生产环境中发生事故时，可以在 Opsgenie 中发出警报。你可以通过在 Opsgenie 中直接创建警报来完成这一操作。当 Opsgenie 与 Jira 服务管理捆绑在一起时，可以从支持请求中创建警报。然而，由于 Jira 服务管理不是开放 DevOps 套件的一部分，必须在 Opsgenie 中手动创建警报。

如何操作

让我们按照以下步骤创建警报：

1. 要创建警报，请在 Opsgenie 导航栏中点击Alerts。

图 12.43 – 从 Opsgenie 菜单中选择 Alerts

1. 一旦进入Alerts部分，请点击Create alert按钮。

图 12.44 – 在 Opsgenie 中创建警报

1. 填写警报的信息。

图 12.45 – 警报创建信息

1. 选择要用于此警报的 API 集成。对于初学者，建议使用Default API，如果你使用的是 Opsgenie 的免费版本，则只有这个选项可用。

图 12.46 – 警报 API 选择

1. 输入应发送的Alert message。此框有 130 字符限制。

图 12.47 – 警报消息

1. 选择警报的优先级。根据你创建的升级规则，此警报将影响/触发该升级规则。

图 12.48 – 警报优先级

1. 如果你知道警报响应者是谁，请填写。否则，路由规则将根据你在路由规则配置中配置的值确定应通知谁。

图 12.49 – 警报响应者

1. 如果你的路由规则配置为利用标签而不是优先级，你可以利用Tags。

图 12.50 – 警报响应者

1. 最后，点击Create创建警报。

图 12.51 – 完整的警报示例

警报现在将显示在警报部分。

图 12.52 – 可用警报的视图

重要提示

根据你的路由规则和升级策略，每个警报都会触发适当的通知，确保你的团队能够对触发警报的问题进行处理和修复。

一旦警报被确认，通知将停止发送。这意味着你的团队已经解决了问题，或者已经确定发生了事故，并且该警报需要升级为一个事件。

如果你点击警报，你将能够查看所有与该警报相关的自动发送的通知。

图 12.53 – 警报历史

警报对于确保你的团队能够及时了解关键事件并知道何时需要介入修复问题至关重要。随着你的生态系统变化，确保不断优化警报设置，确保在问题刚发生时你的团队能够得到适当的通知。

通过 ChatOps 改善团队沟通和响应

当问题出现时，你的团队需要迅速沟通。在数字时代，依赖电子邮件已经无法满足需求，尤其是在每一秒都至关重要的时候。团队之间的即时沟通是最有效的方式。如今，大多数团队已经在使用像 Slack 和 Microsoft Teams 这样的流行通信工具。Opsgenie 与这两个工具都可以集成，从而让你的团队在警报或事件发生时迅速进行沟通。

虽然 Opsgenie 可以与多种即时消息工具进行集成，但此篇将重点介绍如何将 Opsgenie 与 Slack 集成。与 Slack 集成不仅可以让你的团队更快地沟通，还能让你的团队通过 Slack 界面获取警报信息、值班安排等更多内容。

如何操作

将 Opsgenie 与 Slack 集成非常简单。以下步骤将指导你完成配置此集成所需了解的一切：

1. 要启动与 Slack 的集成，请首先进入 Opsgenie 中的团队部分，然后选择你的团队。

图 12.54 – Opsgenie 中可用的团队

1. 进入团队仪表板后，点击左侧的集成。

图 12.55 – 为你的选择的团队选择集成

重要提示

请注意，如果你使用的是 Opsgenie 的免费版本，集成 Slack 的唯一方式就是此方法。虽然通过 Opsgenie 的设置页面还有另一种集成方法，但该方法仅适用于付费使用 Opsgenie 的团队。

1. 点击添加集成以开始。

图 12.56 – 选择“添加集成”以开始

1. 选择Slack。

图 12.57 – 可用的 Opsgenie 集成

1. 按照显示的说明操作。在继续之前，你需要准备一个 Slack 频道。

图 12.58 – Slack 与 Opsgenie 集成说明

1. 在 Slack 中选择频道后，确认你希望在 Opsgenie 中启用的设置。选定满意的选项后，点击保存集成。

图 12.59 – 选择 Slack 集成的配置

1. 配置完集成后，你可以通过进入 Slack 并输入/genie命令来测试配置。

图 12.60 – Slack 和 Opsgenie 在 Slack UI 中的集成

1. 最后，创建一个示例警报，你会看到警报出现在 Slack 中。在 Slack 中，你现在可以处理警报，而无需打断你的工作流程或团队沟通。

图 12.61 – Slack 中的 Opsgenie 警报

现在，Slack 已与 Opsgenie 集成，团队可以在 Slack 中接收 Opsgenie 的通知，这非常有帮助，因为团队不需要切换工具。

第四部分：实践应用

我们将把书中学到的所有知识应用到实践中。我们通过一个示例项目来操作，首先在 Jira Product Discovery 中从一个想法开始，创建 Jira 问题，并在 Bitbucket 中创建开发分支。

然后，我们进行一次提交，查看从测试到部署的管道执行。在此执行过程中，我们可以在 Bitbucket 和 Compass 中查看结果。

我们以展望未来作为结束，人工智能已经在改变许多事情。我们分享一些最后的想法，祝你好运。

本部分包含以下章节：

• 第十三章**， 通过一个真实世界的示例将一切整合起来

• 第十四章**，附录 关键要点与 Atlassian DevOps 工具的未来

第十三章：用一个真实的例子将一切整合在一起

让我们将之前章节中学到的知识运用到实践中，从头到尾完成这个过程。

假设你是DevOps 产品公司（DPI）的员工。你负责使用工具链，通过 Atlassian 产品和第三方产品优化旗舰产品 DPI-Sync 的开发，该产品连接到 Discord 服务器并发送消息。你将如何开始？

为了实现这一点，我们将通过完成以下教程来模拟这一过程：

• 在Jira 产品发现（JPD）中创建一个想法

• 将一个想法连接到 Jira 中的史诗

• 在 Jira 中创建一个故事

• 在 Bitbucket 中创建代码更改

• 在 Bitbucket 中提交更改/启动 Bitbucket Pipeline 构建

• 通过 Bitbucket Pipelines 执行 Snyk 扫描

• 在 Compass 中显示 Bitbucket Pipelines 构建状态

• 部署 Bitbucket Pipelines

• 为 Jira 项目创建 Opsgenie 警报

• 创建一个 bug 修复分支

• 提交一个 bug 修复并观察管道的执行

请记住，这些教程的更详细说明可以在本书的前几章中找到。现在，让我们学习如何启动这个示例项目。

技术要求

对于本章，你需要安装并配置以下 Atlassian 产品：

• JPD

• Jira

• Bitbucket

• Compass

• Opsgenie

本章的示例代码可以在本书 GitHub 仓库的Chapter13文件夹中找到（github.com/PacktPublishing/Atlassian-DevOps-Toolchain-Cookbook/tree/main/Chapter13）。

在 JPD 中创建一个想法

我们将通过决定构建什么来开始开发过程。我们可以从竞争对手、客户和其他来源收集各种意见，以生成新功能和产品的开发想法。

我们将在 JPD 中存储我们的新功能想法。

准备就绪

在我们的JPD项目中，我们必须与 Jira 管理员和 Jira 项目管理员合作，确保我们拥有适当的角色来创建 JPD 想法。

你的项目管理员可以通过执行以下步骤来确保能够创建想法：

1. 从侧边栏选择项目设置选项。

图 13.1 – 选择项目设置

1. 从项目设置侧边栏选项中，展开功能并选择创建想法。出现的页面应如下所示：

图 13.2 – 创建想法

1. 通过切换开关启用允许贡献者创建想法。

   请注意，启用后，贡献者可以创建想法，但不能编辑或删除它们。对于任何想法，贡献者可以添加评论、附件和见解。

如何操作……

我们已经介绍了如何使用创建按钮或在视图中创建想法。现在让我们复习一下如何通过创建按钮创建一个新想法：

1. 点击导航栏上的蓝色创建按钮。

2. 会出现一个模式窗口，显示所需的标准字段。填写这些字段并点击创建按钮。

图 13.3 – 创建一个想法

1. Jira 管理员可以通过创建表单来更改模式窗口中显示的字段。这也可能包括使用模板预填描述字段。

现在我们有一个想法，可以通过添加洞察和其他信息来跟踪其可行性和客户情感。下一步是创建一个 Jira 问题以跟踪开发工作，并将其与原始想法关联。

在 Jira 中将想法与史诗连接

此时，我们开始从构思阶段过渡到实施阶段。这需要我们从 JPD 转移到 Jira。让我们看看如何进行交接。

准备工作

正如我们在第二章的在 Jira 中交付开发想法食谱中看到的，创建史诗之前，请先验证以下内容：

• 至少有一个 Jira 项目可用于容纳该史诗。

• 创建史诗的人需要具有适当的权限，以便在目标项目中创建史诗。这个人应该是 JPD 项目的成员或 Jira 管理员。

当满足这两个条件时，在 JPD 中创建一个作为交付票据的史诗非常容易。

如何操作…

在第二章的在 Jira 中交付开发想法食谱中，你已经看到可以从以下两个位置创建一个史诗：

• 在想法页面上

• 在视图中的想法面板

让我们学习如何从想法页面创建一个史诗，以便熟悉这个过程：

1. 在想法页面，点击交付标签。

图 13.4 – 在想法页面选择“交付”标签

1. 交付标签将展开，给你两个选项：

   • 创建一个新的交付票据（史诗）

   • 创建与现有交付票据的链接

   选择创建交付票据会显示项目的文本框，包括指定问题类型和摘要的区域。这些字段通常是预填的，如下所示：

图 13.5 – 创建交付票据

1. 选择项目和问题类型的值，并在点击创建之前填写所需的摘要。

现在我们在 Jira 中有一个史诗，捕捉了 JPD 中想法所描述的功能。

我们的开发团队不能一次性完成整个史诗的所有工作。通过创建任务，将史诗精细化，描述可以逐步完成的小功能，并逐渐积累功能性，这是推进工作的最佳方式。所以，让我们学习如何做到这一点。

在 Jira 中创建任务

在 Jira 中，我们可以将史诗用作小的、独立功能片段的容器，这些片段作为任务被记录。我们的史诗将这些较小的任务视为其子任务。

让我们直接从史诗页面创建子任务。

准备工作

与之前的步骤类似，我们需要安装和配置 Jira，以便满足以下条件：

• 至少有一个 Jira 项目可容纳任务，并且与史诗相关联。

• 创建任务的人拥有适当的权限，可以在目标项目中创建史诗和任务。此人应为 Jira 项目成员或 Jira 管理员。

当满足两个条件时，创建史诗和子任务变得容易。

如何操作…

你可以在两个位置创建一个子任务，并将其与史诗相关联：

• 在史诗页面

• 在时间轴视图中

让我们看看从每个位置创建子任务的过程。

从史诗页面创建子任务

史诗通常太大，单个开发团队无法在一次 Sprint 中处理。正如那句老话所说，一次吃一口大象。

在 Jira 中，这是通过创建子任务来完成的。让我们看看如何在史诗页面上执行此操作。

1. 获取史诗页面的其中一种方式是从项目侧边栏选择问题页面。

图 13.6 – 从项目侧边栏选择问题

1. 设置相关的筛选条件以限制搜索范围。当你看到史诗时，点击它的关键字或摘要。

2. 进入史诗页面后，点击添加子任务按钮。

图 13.7 – 添加子任务

1. 在子任务部分，选择问题类型（故事用于用户故事），在需要完成的工作区域填写摘要，并点击创建。

图 13.8 – 创建子任务

现在，父史诗已经有一个任务作为子任务进行了关联。

在时间轴视图中创建子任务

时间轴视图将项目的问题按时间顺序展示，以确定项目中所有工作的总体进展。史诗可以放置在时间轴上，并设置预期的开始日期和截止日期。子任务可以在史诗的预期开始日期和截止日期之间创建并进行规划。

在 Jira 项目的时间轴视图中执行以下步骤来创建史诗的子任务：

1. 要进入时间轴视图，请在项目侧边栏中选择时间轴。

图 13.9 – 选择时间线

1. 将鼠标悬停在史诗上，直到出现加号（+）。

2. 从第二个下拉菜单中选择任务类型，并填写需要做什么？区域来填充概要。完成后按Enter键。

图 13.10 – 在时间线视图中输入子故事

现在，子故事将出现在父级史诗下方。

在 Bitbucket 中创建代码更改

此时，我们已准备好开始在 Jira 中开发我们的故事。假设你在一个 Scrum 团队中，且该故事已被选为下一个 sprint，或者你的 Kanban 团队有空余容量可以将该故事从待办事项中移出。不管怎样，现在是时候开始开发了。

这个步骤将指导我们从 Jira（在这里进行故事的规划和设计）转到基于 Git 的工具（在这里我们将创建并存储实现）。这是我们的持续集成与持续部署（CI/CD）管道的起点。

虽然这里的说明适用于连接到 Bitbucket 仓库的 Jira，但对于任何基于 Git 的服务器工具，如 GitHub 或 GitLab，这同样适用，正如我们在第四章中所看到的。

准备开始

在这个步骤中，我们需要确保有一个已创建的 Bitbucket 工作区，并且有一个 Bitbucket 仓库。这个过程在第五章中有说明。在那里，我们通过以下步骤设置了 Bitbucket：

1. 首先，我们创建了一个 Bitbucket 工作区。如果需要的话，我们还创建了一个项目。

2. 然后，我们创建了一个 Bitbucket 仓库。

现在我们已经创建了工作区和仓库，我们需要将其连接到我们的 Jira 项目。我们在第一章中学习了如何将 Jira 项目连接到 Bitbucket 仓库。在那里，我们执行了以下步骤：

1. 首先，作为 Jira 项目管理员，我们选择了项目设置下的工具链。

2. 然后，我们在工具链页面上选择了构建部分。

3. 在工具链页面，我们点击了添加。

4. 在这里，我们选择了Bitbucket作为仓库提供者。

5. 最后，我们选择了要添加的仓库并点击了添加仓库。

现在我们已经准备好开始开发，前提是 Jira 项目已连接到 Bitbucket 仓库。

如何操作…

要开始开发，我们必须在 Git 中创建一个分支来存放新的或更改过的文件。如果我们的 Git 仓库已连接到 Jira 项目，我们可以直接从 Jira 创建分支，且该分支将与描述上下文的任务关联。

从 Jira 任务中创建该分支，请执行以下步骤：

1. 寻找 Jira 任务中的开发部分。该字段组记录了与 Jira 任务相关的分支、提交和拉取请求。以下截图显示了我们可以在哪里找到这些开发字段：

图 13.11 – 开发信息

1. 要创建分支，点击创建分支链接。您将被带到一个页面，可以在该页面上配置仓库的分支、分支类型和分支名称。以下截图显示了这一过程：

图 13.12 – 创建分支

在您的本地仓库副本上点击git checkout，如下所示：

图 13.13 – Bitbucket 上的分支页面

通过这样操作，您已使用 Jira-Bitbucket 集成将 Jira 问题与 Bitbucket 分支连接，从而可以开始开发。

在 Bitbucket 中提交更改/启动 Bitbucket 管道构建

此时，我们正在进行开发过程中的实现。我们对代码进行更改，并将这些更改提交到 Bitbucket。一旦我们对 Bitbucket 仓库进行提交，我们希望 Bitbucket Pipelines 启动 CI 构建，包括任何测试和安全扫描。

准备工作

将我们在本书 GitHub 仓库中Chapter13文件夹中的代码放入您为前一节创建的 Bitbucket 仓库中。这还包括复制bitbucket-pipelines.yml文件，并确保它位于仓库的根目录。

如何操作……

我们将在 Bitbucket 用户界面直接进行更改，而不是远程操作。一旦提交，Bitbucket 管道应当执行。为了启动这个过程，请执行以下步骤：

1. 在 Bitbucket 仓库页面，选择仓库侧边栏中的源代码。

图 13.14 – 选择源代码

1. 在源代码窗口中，打开分支下拉菜单，选择您在前一节中创建的分支。

图 13.15 – 选择分支

1. 选择您希望编辑的文件。如果文件是嵌套的，请先选择文件夹。在本例中，我们将编辑index.js。

图 13.16 – 选择要编辑的文件

1. 在index.js文件的编辑页面，选择编辑。

图 13.17 – 选择编辑

1. 完成更改后，选择提交，将更改添加并跟踪到 Git 中。

图 13.18 – 提交

1. 在弹出框中，提供提交信息并选择提交。为了使提交与 Jira 关联，提交信息必须以相关 Jira 问题的 ID 开头。

2. 一旦提交完成，Bitbucket Pipelines 应该会执行，执行包括测试、扫描和部署步骤在内的bitbucket-pipelines.yml文件中的内容。您可以通过在仓库侧边栏中选择管道来查看部署过程及其进度。

现在我们的流水线正在运行，让我们通过集成 Snyk 来增强它，这将执行安全扫描并将我们的流程更多地移向DevSecOps。

通过 Bitbucket Pipelines 执行 Snyk 扫描

Snyk 是几个可以与 Bitbucket 和 Bitbucket Pipelines 紧密集成的安全工具之一。这种紧密集成允许在测试的一部分中执行 Snyk 扫描以查找安全漏洞，当它是 Bitbucket 流水线中的一个步骤时。

让我们学习如何设置这个集成。

准备工作

Snyk 与 Bitbucket 的集成采用以下形式：

• Snyk 被设置为 Bitbucket 的安全提供者，以便在存储库上执行自动化扫描，并在存储库侧边栏的安全部分中显示其结果。

• Snyk 管道可以作为 Bitbucket Pipelines 执行的一部分执行 Snyk 扫描。

让我们来看看如何设置这个。

将 Snyk 设置为安全提供者

我们将从为 Bitbucket 设置 Snyk 作为安全提供者开始。为此，请执行以下步骤：

1. 在您的 Bitbucket 存储库中，从存储库侧边栏中选择安全。

图 13.19 – 安全

1. 如果您没有 Snyk 帐户，请选择安装 Snyk并设置 Snyk 帐户。

2. 将出现一个模态窗口，询问您是否请求访问整个工作区。选择允许以继续将 Snyk 集成到 Bitbucket 中。

图 13.20 – 将 Snyk 与 Bitbucket 集成

1. 接下来，Snyk 将要求您登录或创建新的 Snyk 帐户。注册将使您享受免费试用期，试用期结束后，您将转入免费计划。按下注册或登录创建或输入您的 Snyk 帐户。

2. 设置好你的帐户并与 Bitbucket Cloud 集成后，你的存储库将在存储库侧边栏中包含以下部分（已注释）：

图 13.21 – Snyk 安全

将存储库导入到 Snyk 并设置 Snyk 项目，您可以定期执行扫描并接收有关发现的任何漏洞的通知。我们还讨论了如何通过使用 Snyk Pipe 将 Snyk 作为流水线的一部分来运行。让我们学习如何实现这一点。

设置 Snyk Pipe

我们可以在bitbucket-pipelines.yml文件中添加一个步骤，以使用 Snyk 执行安全扫描。我们最初在第六章中介绍了这一点；在这里我们再次强调必要的步骤：

1. 打开bitbucket-pipelines.yml文件，以便您可以在 Bitbucket UI 中进行编辑。编辑文件应该显示 Bitbucket Pipelines 编辑器，如下截图所示：

图 13.22 – 流水线编辑器

1. 将以下代码片段添加为 bitbucket-pipelines.yml 文件中的独立步骤。要获取 Snyk 令牌，请进入 Snyk 账户的API 令牌部分，并将其保存为安全的仓库变量：

   -pipe: snyk/snyk-scan:1.0.1
       variables:
         SNYK_TOKEN: $SNYK_TOKEN
         LANGUAGE: "node"
   

2. 将更改提交到bitbucket-pipelines.yml文件。

这样一来，Snyk 扫描已被设置为 Bitbucket Pipelines 中的一步。

现在 Snyk 已配置完成，我们可以轻松地在管道中执行 Snyk 扫描。让我们来看看执行 Snyk 扫描的不同方法。

如何操作…

现在我们已经将 Snyk 配置与 Bitbucket 连接，接下来让我们学习如何执行 Snyk 扫描：

1. 因为任何提交都会自动执行管道，所以将你的步骤放在常用的分支或默认设置中，这样就会执行 Snyk 扫描。

2. 如果你知道将 Snyk Pipe 放入了哪个管道，你可以通过选择分支、提交或标签，选择该管道并点击运行来手动执行该管道。此过程在第六章的手动执行一文中有详细说明。

接下来，我们将考虑各种场景：如果测试通过，我们将从 CI 过渡到 CD。

在 Compass 中显示 Bitbucket Pipeline 构建状态

Compass 将开发工作组织成组件，并显示这些组件的状态。影响这些组件的事件包括构建和部署。Compass 可以从 Jira 和 Bitbucket 收集信息，并在一个界面中展示。

在本篇中，我们将在 Bitbucket 中进行更改，并查看其在 Compass 中的影响。

准备工作

如果你还没有完成此操作，你需要将 Bitbucket 连接到 Compass。如何操作的说明可以在第十一章的将 Compass 与 Bitbucket Cloud 集成一文中找到。管理员在最初安装 Compass 时，也可以通过另一种方式将 Bitbucket 连接到 Compass。让我们看看此时可以进行哪些操作：

1. Compass 会识别 Bitbucket 是否是云组织的一部分。如果它发现了 Bitbucket 仓库，它将提供将其映射为 Compass 组件的选项。确认 Compass 已找到所需的 Bitbucket 项目。

图 13.23 – 将仓库导入为 Compass 组件

1. 此时，你需要允许 Compass 连接到 Bitbucket。为此，点击授予 访问权限按钮。

图 13.24 – 授权 Compass

授权完成后，你可以查看关于 Bitbucket 仓库的信息，因为它们已经被映射为 Compass 组件。

图 13.25 – Compass 组件

如何操作…

现在我们的 Bitbucket 仓库已被映射为 Compass 组件，让我们看看在 Bitbucket 中进行更改时 Compass 会发生什么。为了方便查看，可能需要将 Compass 和 Bitbucket 打开在不同的浏览器标签页或窗口中：

1. 在Compass选项卡或窗口中，设置与您的 Bitbucket 仓库对应的组件。点击活动以查看该组件的最近活动。

图 13.26 – 选择组件的活动

1. 在Bitbucket选项卡中，对仓库进行更改。点击编辑器中的提交按钮来完成此操作。

2. 在弹出框中，输入提交信息和其他所需信息。点击提交以提交更改。

   在 Bitbucket 中，进入Pipelines视图，确认管道已经执行。

图 13.27 – 查看管道执行情况

1. 转到 Compass 正在运行的浏览器标签页。在映射到 Bitbucket 仓库的组件的活动视图中，确认部署已经发生。

图 13.28 – 在 Compass 中看到的部署

至此，我们已确认 Bitbucket 中的操作会显示在 Compass 中。这些信息包括部署记录。

在我们的示例场景中，我们的开发团队将与运维团队接收相同的警报通知。我们来看看如何做到这一点。

为 Jira 项目创建 Opsgenie 警报

在第十二章的设置 Opsgenie 团队食谱中，我们学习了如何设置 Opsgenie。这使我们能够创建团队和通知计划，当警报发生时，系统会做出反应。

准备就绪

如果您在第十二章中没有将您的 Jira 项目连接到 Opsgenie，或者创建了新的 Jira 项目，请按照以下步骤操作：

1. 在您的项目中，选择项目设置，然后选择Toolchain。

2. 在Toolchain页面中，展开操作部分并选择+ 添加值班团队**。

图 13.29 – 添加值班团队

1. 在弹出框中，输入团队名称。在输入过程中，操作将以下拉菜单形式出现，显示您输入的团队名称。选择下拉菜单中显示的创建…选项。新团队名称显示为下拉菜单后，如下图所示，点击创建。

图 13.30 – 添加值班团队

1. 将鼠标悬停在您创建的团队上。点击更多操作（…）图标，然后选择在 Opsgenie 中打开。

图 13.31 – 在 Opsgenie 中打开

1. Opsgenie 会在团队页面打开。查看值班部分，验证以下内容：

   1. 路由规则指向一个升级策略。如果没有，请参考第十二章中的升级策略和规则食谱，创建一个升级策略并设置路由规则。下面的截图展示了一个示例：

图 13.32 – 路由规则和升级策略

1. 在值班安排中已识别出一位团队成员。这在以下截图中展示：

图 13.33 – 值班安排

如果你的团队成员有值班安排，并且已经识别了团队成员，并且路由规则指向了升级策略，那么你应该能够接收到指向你团队的警报。让我们通过在 Opsgenie 中创建警报来学习如何进行测试。

如何操作…

我们将直接在 Opsgenie 中创建一个警报，并验证通知是否发送给值班团队成员。通常，Opsgenie 通过与Jira 服务管理或 DevOps 监控工具的集成来接收警报。我们进行此测试是为了验证我们的模拟过程。

在 Opsgenie 中执行以下步骤来创建警报：

1. 在 Opsgenie 中，点击菜单栏中的警报项。

图 13.34 – 警报

1. 在警报页面上选择创建警报。

图 13.35 – 创建警报

1. 在弹出的窗口中，选择默认 API作为API 集成，并在响应者区域搜索你的团队。选择这些选项后，填写警报消息并点击创建。

图 13.36 – 设置并创建新警报

1. 验证警报是否已在 Opsgenie 中创建。

图 13.37 – Opsgenie 中的警报

1. 你也可以查看与值班团队成员相关联的电子邮件，确认是否已发送电子邮件通知。

图 13.38 – 警报电子邮件通知

如我们所见，开发人员可以接收来自事故和运维人员的通知，这使得开发人员和运维人员能够一起解决生产问题。如果根本原因被发现是 bug，开发人员可以通过创建 bugfix 分支来添加修复。我们将在下一个示例中看到这个过程如何进行。

创建 bugfix 分支

出现了问题！QA 在新版本中发现了一个 bug。他们在 Jira 中写下了一个 bug，并将其分配给你。你需要做的是在 Bitbucket 中创建一个分支，包含解决方案，并将其与 Jira 问题连接起来。

我们将在本示例中模拟前述场景。你首先需要做的是在 Jira 中创建 bug。

准备工作

我们的第一步是使用 Jira 创建 bug。为此，请执行以下步骤：

1. 在 Jira 屏幕顶部选择创建按钮。

2. 在出现的弹窗中，填写摘要等必填项，并确保项目和问题类型（Bug）字段正确。点击创建。

   你的新 bug 应该出现在项目中。

图 13.39 – 新的 Bug

在 Jira 中创建了 bug 之后，现在是在 Bitbucket 中创建 bug 修复分支的时候了。让我们进一步检查一下。

如何执行…

继续使用与 Bitbucket 仓库中在 Bitbucket 中创建代码更改配方提供的相同 Jira 项目，我们可以通过执行以下步骤轻松地创建我们的 bug 修复 Bitbucket 分支：

1. 在我们的 Jira bug 中，转到开发部分，选择创建分支。

图 13.40 – 创建分支

1. Bitbucket 中的页面将作为新的浏览器选项卡或窗口显示。它将填写以下信息：

   • 分支名称预填写了 Jira 问题的 ID

   • 父分支

   • 分支类型

   • 仓库名称

   确保这些信息正确，然后点击创建。

图 13.41 – 创建分支

1. 你的代码库中应该显示分支，具有在本地环境中检出并查看源码的可用操作区域。

图 13.42 – 查看分支

有了分支创建后，我们可以开始开发。让我们更详细地看看这个过程。

提交 bug 修复并观察流水线的执行

我们一直在认真排查我们的 bug 的根本原因，并且我们已经开发了一个修复方案。当我们将该修复提交到代码库时会发生什么？我们希望进行测试和扫描，以确保代码质量高。

这要求 Bitbucket 流水线在提交发生时准备好执行。让我们学习如何实现这一点。

准备工作

此配方的先决条件与Bitbucket 提交更改/启动 Bitbucket 流水线生成的配方相同——即，我们需要确保在我们的代码库中有一个bitbucket-pipelines.yml文件，并且它位于代码库目录结构的根目录中。

如何执行…

就像在Bitbucket 提交更改/启动 Bitbucket 流水线生成的配方中一样，我们将通过执行以下步骤来观察流水线的执行：

1. 在我们的 bug 修复分支中，我们必须在文件中进行更改。我们可以通过编辑器中的提交按钮提交我们的更改。

2. 在模态框中，输入提交消息字段中的值。要将提交记录到我们的 Jira 问题中，消息需要以我们 Jira 问题的 ID 开头。进行必要的更改，然后点击提交。

3. 转到流水线视图。流水线应该根据最近的提交正在执行。

图 13.43 – 流水线视图

1. 单击与流水线执行对应的行以查看流水线执行详细信息。

图 13.44 – 流水线执行详细信息

有了这个，我们学会了如何根据 bug 修复分支的提交执行流水线。

附录 – 关键要点和 Atlassian DevOps 工具的未来

在本书中，我们演示了如何轻松将集成应用于核心的 Atlassian 工具并创建 DevOps 工具链。但这常常引发一个问题，“这就完了吗？”

好消息是，Atlassian 正在不断为其云产品添加新功能，这些功能在本书前几章中我们已展示过。许多这些功能允许 Atlassian 产品之间轻松互联，以提高可见性和状态跟踪。

本章将专注于 Atlassian 产品的短期未来及你如何使用这些产品。我们将重点讨论以下主题：

• Atlassian Intelligence

• 设置工具链的最佳实践

让我们从查看 Atlassian 在人工智能（AI）和机器学习（ML）的应用开始，展望未来。

Atlassian Intelligence 和其他 AI 技术

Atlassian 于 2023 年 4 月首次推出了Atlassian Intelligence，它改变了用户使用 Atlassian 工具的方式。并非所有工具都启用了 Atlassian Intelligence，但主要产品——Jira、Confluence 和 Jira 服务管理——都拥有令人兴奋的新功能，使得使用这些工具变得更加简单。

从 Jira 开始，Atlassian Intelligence 使得查找问题变得更加容易。在 Atlassian Intelligence 引入 Jira 之前，用户可以创建复杂的Jira 查询语言（JQL）搜索来查找感兴趣的问题。现在，借助 Atlassian Intelligence，你可以使用自然语言（NL）简单地询问 Jira 你感兴趣的问题。然后，Atlassian Intelligence 会代表你编写 JQL 搜索并返回相关结果。

Atlassian Intelligence 不仅仅帮助你处理搜索查询。当你创建问题时，你可以利用 Atlassian Intelligence 的力量来帮助你创建问题。Atlassian Intelligence 可以帮助你头脑风暴，并帮助填写问题的描述。每当你需要一点推动力或灵感来开始时，这非常有用。

最后，Atlassian Intelligence 帮助你改变写作的语气。语气有时很难通过文字传达，而用户与 Jira 互动的主要方式就是书面语言。这可能导致冲突、困惑和分歧。幸运的是，Atlassian Intelligence 通过将文本改写成不同类型的语气，帮助用户改善写作。

Confluence 还具有一些非常激动人心的新功能，这些功能由 Atlassian Intelligence 提供支持。类似于 Jira 的 JQL，Confluence 也有强大的搜索功能，允许用户查找数据。过去，用户通过 Confluence 页面及相关页面进行数据搜索并获得返回结果。现在，借助 Atlassian Intelligence 的强大功能，不仅会返回相关页面，还会返回针对用户查询的答案。这改变了用户在 Confluence 中搜索信息的方式，因为用户不再依赖于关键词寻找信息，而是 Atlassian Intelligence 为你构建一个答案。最棒的是，用户可以使用自然语言 (NL) 在 Confluence 中提问，而不必依赖关键词。

Confluence 中的另一个 Atlassian Intelligence 功能是帮助你查找单词的能力。许多团队有专门属于自己团队或公司的技术术语。这些术语对于团队成员来说通常是常识，但对于新加入的团队成员来说，跟上这些术语的定义可能会有些挑战。幸运的是，借助 Atlassian Intelligence，这些新员工可以轻松地查找 Confluence 中的所有相关数据，帮助他们了解这些术语的含义。这一点非常棒，因为它不会到互联网上去寻找术语的含义，而是从公司自己的数据中获取相关信息，这增加了找到相关定义的可能性。

在 Confluence 中值得注意的最后一个 Atlassian Intelligence 功能是为用户总结 Confluence 页面内容的能力。页面通常包含大量数据，用户可能难以完全消化页面中的所有信息。借助 Atlassian Intelligence，用户可以获得页面的总结视图，突出显示用户应了解的关键信息。

Atlassian Intelligence 仍然相对较新，Atlassian 也在不断改进它。请留意，Atlassian 将继续扩展 Atlassian Intelligence 的功能，并将其推广到 Atlassian 套件中的其他产品。

设置工具链的最佳实践

正如你在本书中学到的那样，设置所有工具并进行配置是一个复杂的过程。此时，你应该已经配置好了所有工具，DevOps 工具也应该准备好供你的团队使用，以提高协作和效率。接下来是一些在设置工具链时你应考虑的最佳实践，以确保更顺利地完成设置：

• 定义明确的目标：在开始部署 DevOps 工具之前，先弄清楚你想要实现什么。许多不同的 DevOps 工具几乎做着相同的事情，选择其中一个可能并不简单。本书重点介绍了 Atlassian 工具，但也有许多不同的替代品。如果你公司的目标是保持在 Atlassian 生态系统内，那么本书已经为你提供了实现这一目标的方式。

• 选择合适的工具：明确目标后，你需要选择合适的工具集。如前所述，许多 DevOps 工具在价格和功能上非常相似。评估每个工具，了解每个工具在你和团队的需求下的优缺点。避免注册多个做同一件事的工具，因为这只会增加 DevOps 工具的复杂性，并且提升整体开支和团队效率低下。

• 规范化你的工作流程：为每个开发团队创建独特的工作流程或过程可能会很有诱惑力。理想情况下，你的公司应该有一个明确定义的过程，来指导如何使用 DevOps 工具。避免不必要的步骤或可能引起团队困惑的步骤。采用相同的操作模型有助于提高团队协作、沟通和效率，因为大家都将使用共同的语言。确保你的流程有充分的文档支持，并且在新员工入职时，他们能够熟悉你的流程。随着你对工具和流程的深入了解或提升效率，定期优化你的流程。

• 自动化过程：尽可能多地实现自动化；这并不意味着自动化一切。自动化你流程和工具链中有意义的部分。不要为了自动化而自动化。直到你的团队或过程成熟之前，可能仍然需要人为干预。如果你的团队还没有完全理解如何手动完成工作，不要在第一天就试图自动化一切。

• 跟踪性能：监控和衡量 DevOps 工具和流程的表现。始终有改进的空间，定期回顾你的工具和流程可以帮助提高团队的效率和产出。围绕 关键绩效指标 (KPIs) 建立一些衡量标准，引导团队完成他们的 DevOps 旅程。

• 维护安全性和合规性：定期审查你的配置和流程，确保你的团队能够跟上网络安全领域的最新趋势和威胁。审查代码审查实践、漏洞扫描和访问控制策略，确保你的团队始终适应不断变化的网络环境。

• 协作与沟通：拥有出色的 DevOps 工具是非常棒的，但不管你的工具链有多强大，务必鼓励你的团队进行协作和沟通。你的 DevOps 工具是为了帮助团队，但它们不应该取代团队成员之间的互动。

• 培训与发展：最后，培训你的团队如何使用你的工具。DevOps 对你的团队来说可能会有些混乱，特别是对于那些可能不太熟悉你们基础设施的新成员。养成培训新成员并为现有员工提供复训的习惯。当你对流程和工具链进行更改和改进时，记得更新文档，并在需要时与团队其他成员分享这些更改。鼓励分享新发现或更好的使用工具的方式，形成一种分享文化。

总结

总结来说，DevOps 更像是一段旅程，而非一个终点。本书的设计目的是让你起步，帮助你启动 DevOps 工具链。随着团队继续使用本书中配置的工具，你应该不断改进工具链和定义的流程。本书探讨了整个 DevOps 生命周期，涵盖了 Jira、Jira 产品发现、Bitbucket、Compass、Opsgenie 等工具的配置。这仅仅是开始，你的团队自然会继续调整并对配置进行更改。

本书阐述了选择正确的 DevOps 工具组合的重要性和价值。Atlassian 工具套件设计得相互协作，任何使用 Jira 或 Confluence 的团队都应考虑将其余的 Atlassian 工具整合进来。

在本书结束时，我们想提醒你，这仅仅是一个开始。现在你已经拥有了一套功能完善的工具，是时候让你的团队真正利用 DevOps 的力量，把软件质量和开发效率提升到新的水平。DevOps 是关于持续学习和改进的，你的工具也应该遵循这一实践。

我们希望本书能为你提供有价值的见解、知识和灵感，帮助你领导团队的 DevOps 工作。感谢你与我们一起走过这段旅程，祝你一切顺利！