15、问题跟踪器的选择与实践-优快云博客

本文链接：https://blog.youkuaiyun.com/ruby5/article/details/150369682

问题跟踪器的选择与实践

1. 选择问题跟踪器的考虑因素

在选择问题跟踪器时，除了要支持基本工作流程外，还有许多其他因素需要考虑：

1.1 规模需求

大多数工具在约 20 人规模内运行良好，但超过这个规模，就需要考虑性能和许可要求。
需要思考能够跟踪多少问题以及多少用户需要访问问题跟踪器。

1.2 许可数量

免费软件在这方面更具优势，因为专有软件的定价可能不直观。免费软件通常免费使用，还可选择支持许可。
本章提到的大多数问题跟踪器是免费软件，Jira 除外。

1.3 性能限制

性能通常不是限制因素，因为大多数跟踪器使用如 PostgreSQL 或 MariaDB 等生产级数据库作为后端。
不过，评估打算部署的系统性能是个好习惯，特殊的使用场景可能会引发性能问题。例如，大多数问题跟踪器使用关系型数据库作为后端，在进行递归查询时，关系型数据库不太适合表示层次树结构。

1.4 支持选项及质量

在实际使用前很难确定支持质量，但有一些评估思路：
- 开源项目的支持依赖于用户社区规模，通常也有商业支持提供商。
- 商业问题跟踪器可能有付费和社区支持。

1.5 是否使用托管的问题跟踪器

有很多公司提供问题跟踪器托管服务，如 Atlassian 的 Jira 跟踪器，既可以安装在客户场所，也可以由 Atlassian 托管；还有 Trello 公司的 Trello。
在自己的网络中部署问题跟踪器通常不难，一般需要数据库后端和 Web 应用后端层，最难的部分通常是与认证服务器和邮件服务器的集成。使用托管跟踪器更简单，但有些组织因法律或其他原因不能将工作数据泄露到自己的网络之外，这些组织只能在自己的网络内部署问题跟踪器。

1.6 问题工作流系统是否适应需求

一些系统，如 Jira，允许使用高度灵活的状态机定义流程并通过集成编辑器进行编辑，而其他系统的流程则更简约。正确的解决方案取决于自身需求，有些人一开始想要复杂的流程，后来发现只需要开放和关闭状态；而有些人则需要复杂流程来支持其复杂的工作过程。
可配置的流程在大型组织中很有用，它可以封装不那么明显的流程知识。

1.7 是否支持所选的敏捷方法

本章提到的大多数问题跟踪器的底层数据模型足够灵活，能够表示任何类型的敏捷过程，本质上只需要一个可配置的状态机。
支持敏捷方法的额外功能通常分为可视化和报告两类。虽然这些功能不错，但一些经验不足的团队领导可能过于关注这些功能，实际上它们带来的价值没有最初想象的那么大。

1.8 是否能与组织内其他系统轻松集成

问题跟踪器可能集成的系统包括代码仓库、单点登录、电子邮件系统等。例如，构建失败时，构建服务器可以自动在问题跟踪器中生成一个工单并分配给导致构建失败的开发人员。
由于主要关注开发工作流，所以主要需要与代码仓库系统集成，本章探讨的大多数问题跟踪器都有某种形式的与代码仓库系统的集成。

1.9 跟踪器是否可扩展

问题跟踪器有某种形式的 API 作为扩展点通常很有用，API 可用于与其他系统集成，也可自定义跟踪器以适应组织的流程。
例如，需要在公开可见的监视器上显示当前开放问题的 HTML 格式显示，或者让问题跟踪器触发部署系统中的部署，都可以通过良好的 API 实现。

1.10 是否提供多项目支持

如果有多个团队和项目，为每个项目设置单独的问题跟踪器可能很有用。因此，问题跟踪器的一个有用特性是能够将自身划分为多个子项目，每个子项目在系统内有独立的问题跟踪器。
但这也存在权衡，如果有多个单独的问题跟踪器，如何在它们之间移动问题是个问题。从 DevOps 的角度来看，工具应该促进团队协作而不是将团队分开。

1.11 是否支持多个客户端

虽然这通常不是选择问题跟踪器的关键接受要求，但通过多个客户端和接口访问问题跟踪器会很方便。例如，开发人员在集成开发环境中工作时能够访问问题跟踪器就非常便利。
一些使用免费软件的组织更喜欢完全基于电子邮件的工作流，但这种需求在企业环境中很少见。

2. 问题跟踪器泛滥的问题

如今设置问题跟踪器技术上很容易，团队常常会设置自己的问题跟踪器来处理自己的问题和任务。但这也带来了问题跟踪器泛滥的问题，而编辑器泛滥通常不是问题，因为编辑器是开发人员的个人工具，主要不是用于与他人共享协作界面。

问题跟踪器泛滥的原因包括：
- 大型组织可能会标准化一种很少有人喜欢使用的跟踪器类型，例如只考虑了一种团队（如质量保证团队或运营团队）的需求。
- 为问题跟踪器购买的许可证数量有限，其余团队只能自行解决。

不同团队使用不同的问题跟踪器会导致组织整体效率低下，尽管对于某个团队来说，能够选择自己的工具可能被视为一种胜利。DevOps 的核心思想之一是让不同团队和角色更紧密地合作，而相互不兼容的协作工具的泛滥不利于实现这一目标。使用免费软件跟踪器至少可以解决许可证数量有限的问题，但找到一个让所有人都满意的系统要困难得多。可以通过限制选择标准的范围，让实际使用问题跟踪器的人满意，而不是只关注漂亮的报告图表，更要注重实际解决问题。

3. 部分问题跟踪器介绍

3.1 Bugzilla

Bugzilla 可以说是所有问题跟踪器系统的鼻祖，自 1998 年就已存在，被许多知名组织使用，如 Red Hat、Linux 内核项目和 Mozilla 项目。
它是由 Mozilla 项目维护的免费软件，用 Perl 编写，主要专注于跟踪 bug，处理其他类型的任务（如提供维基）需要单独进行。
许多组织将 Bugzilla 用作面向公众的工具，用于报告问题，因此它具有良好的安全特性。可以在 https://landfill.bugzilla.org/bugzilla - tip/ 测试其开发版本的最新功能。
Bugzilla 支持自定义，可以添加自定义字段和自定义工作流，并且有 XML - RPC 和 JSON REST API。由于存在时间长，有许多扩展和插件可用，包括替代客户端。

Bugzilla 的默认工作流状态如下：
| 状态 | 描述 |
| ---- | ---- |
| Unconfirmed | 非授权用户提交的新 bug 从该状态开始 |
| Confirmed | 如果 bug 被确认值得调查，进入该状态 |
| In progress | 开发人员开始解决 bug 时使用该状态 |
| Resolved | 开发人员认为已完成 bug 修复时，将其置于该状态 |
| Verified | 质量保证团队确认 bug 已修复时，进入该状态 |

3.1.1 实践 Bugzilla

可以使用 Docker 启动 Bugzilla：

docker run -p 6050:80 dklawren/docker-bugzilla

访问 http://localhost:6050 ，提交 bug 需要账户，可以使用管理员账户（用户名：admin@bugzilla.org，初始密码：password）或创建新账户。创建和解决 bug 的步骤如下：
1. 选择“Open a New Account”，输入电子邮件地址，会收到带有链接的确认邮件，确保链接中的端口号正确，完成账户创建。
2. 使用“File a Bug”选项创建新 bug，需要提供产品和组件信息，可以使用“TestProduct”和“TestComponent”。
3. 打开 bug 后可以进行评论，根据访问级别还可以将其移动到新状态。
4. 可以使用简单搜索页面或高级搜索页面搜索 bug，高级页面可以搜索大多数字段组合。
5. 完成后将 bug 标记为已解决。

3.2 Trac

Trac 是一个易于设置和测试的问题跟踪器，其主要吸引力在于它体积小，能将多个系统集成在一个简洁的模型中。它是最早展示问题跟踪器、维基和仓库查看器可以有益集成的工具之一。
Trac 用 Python 编写，由 Edgewall 以免费软件许可证发布，最初采用 GPL 许可证，自 2005 年起采用 BSD 风格的许可证。
它通过插件架构实现高度可配置，有许多插件可用，部分插件列表可在 https://trac - hacks.org 查看。Trac 开发节奏保守，很多用户对此很满意，并且有 XML - RPC API 用于读取和修改问题。它传统上只与 Subversion 集成，现在也支持 Git。此外，它还有集成的维基功能，是一个相当完整的系统。

3.2.1 实践 Trac

使用 Docker 启动 Trac：

docker run -d -p 6051:8080 barogi/trac:1.0.2

访问 http://localhost:6051/ 会显示可用项目列表，初始只有默认项目。右侧菜单显示默认的基本功能：
- Wiki：传统的维基，可用于编写开发相关文档。
- Timeline：显示 Trac 中发生的事件。
- Roadmap：显示按里程碑组织的工单。
- View Tickets：显示工单，有多种可能的报告，还可以创建新报告。
使用用户名和密码“admin”登录后，会出现“New Ticket”菜单选项。创建工单时，下方窗口会实时更新预览。工单初始处于“new”状态，使用“Modify”按钮可以更改状态，解决工单并评论后，状态将变为“closed”。
Trac 的一大卖点是维基、问题跟踪器和仓库的紧密集成。编辑主维基页面时，使用简单的维基语法创建新标题，提交更改后，问题标识符会变为可点击的，点击可访问问题。如果在代码更改的提交消息中提及 bug，Trac 会在其变更集浏览器中使其也可点击。
通过管理界面可以对 Trac 实例进行部分定制，但有些方面需要在文件系统中配置，如用户、组件、里程碑、优先级、解决方案、严重性和工单类型。Trac 有可配置的状态机，默认新安装的状态机比最小的开放/关闭状态机稍复杂，状态如下：
- New
- Assigned
- Accepted

以下是 Trac 状态机的 mermaid 流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([New]):::startend --> B(Assigned):::process
    B --> C(Accepted):::process

通过对 Bugzilla 和 Trac 的介绍和实践，我们可以看到不同问题跟踪器的特点和使用方法，在选择问题跟踪器时，可以根据自身需求进行综合考虑。

3.3 Redmine

Redmine 是一款功能全面的项目管理工具，同时具备问题跟踪功能。它提供了丰富的特性，能够满足项目管理中的多种需求，如任务分配、进度跟踪、文档管理等。
Redmine 基于 Ruby on Rails 框架开发，具有良好的可扩展性和灵活性。它支持多语言界面，方便不同地区的用户使用。
该工具可以对项目进行细致的管理，包括创建项目、定义项目成员角色和权限、设置项目的里程碑和版本等。在问题跟踪方面，它允许用户创建详细的问题描述，为问题添加优先级、严重程度、类别等属性。

Redmine 的主要功能特点如下：
| 功能 | 描述 |
| ---- | ---- |
| 项目管理 | 支持创建多个项目，对项目进行分类和层级管理 |
| 问题跟踪 | 可创建、编辑、分配和跟踪问题，设置问题的状态和解决结果 |
| 文档管理 | 提供文档上传和下载功能，方便团队共享项目相关文档 |
| 进度跟踪 | 可以查看项目的整体进度和各个任务的完成情况 |
| 权限管理 | 能够为不同角色的用户分配不同的操作权限 |

3.3.1 实践 Redmine

可以使用 Docker 来部署 Redmine，以下是启动 Redmine 的命令：

docker run -d -p 6052:3000 redmine

访问 http://localhost:6052 ，首次访问时需要进行一些初始化设置，如设置管理员账户、数据库连接等。
创建项目：登录后，点击“项目”菜单，选择“新建项目”，填写项目名称、描述等信息，然后点击“创建”。
创建问题：进入项目页面，点击“问题”菜单，选择“新建问题”，填写问题的标题、描述、优先级等信息，点击“保存”。
跟踪问题状态：在问题列表中，可以看到问题的当前状态，通过操作按钮可以更改问题的状态，如将问题标记为“已解决”“已关闭”等。

3.4 GitLab 跟踪器

GitLab 是一个集成了版本控制、问题跟踪、持续集成等多种功能的平台，其问题跟踪器是其中的一个重要组成部分。
GitLab 跟踪器与 Git 版本控制系统紧密集成，方便开发人员在代码管理的同时进行问题跟踪。它支持在代码提交时关联问题，通过提交信息自动更新问题的状态。
该跟踪器提供了直观的界面，用户可以方便地创建、查看和管理问题。它还支持对问题进行标签分类、设置里程碑和截止日期等操作，有助于提高团队的工作效率。

GitLab 跟踪器的优势如下：
| 优势 | 描述 |
| ---- | ---- |
| 与 Git 集成 | 无缝结合代码管理和问题跟踪，提高开发效率 |
| 可视化管理 | 提供直观的界面，方便查看和管理问题 |
| 团队协作 | 支持团队成员之间的评论和讨论，促进信息共享 |
| 自动化流程 | 可以设置自动化规则，根据条件自动更新问题状态 |

3.4.1 实践 GitLab 跟踪器

首先，需要在 GitLab 平台上创建一个项目。登录 GitLab 账户，点击“新建项目”，填写项目名称和描述，选择项目的可见性，然后点击“创建项目”。
创建问题：进入项目页面，点击“问题”菜单，选择“新建问题”，填写问题的标题、描述、标签等信息，点击“提交问题”。
关联代码提交：在代码提交时，在提交信息中使用特定的语法关联问题，例如“Fix #123”，其中“#123”是问题的编号。提交代码后，问题的状态会自动更新。
查看问题状态：在问题列表中，可以查看问题的当前状态、关联的提交记录等信息。通过筛选和排序功能，可以快速定位到需要关注的问题。

3.5 Jira

Jira 是一款商业的问题跟踪和项目管理工具，以其强大的功能和高度的可定制性而闻名。它广泛应用于软件开发、项目管理等领域，许多大型企业和团队都选择使用 Jira 来管理他们的工作流程。
Jira 提供了丰富的插件和集成选项，可以与其他工具（如代码仓库、QA 工具、自动化测试工具等）进行深度集成，实现工作流程的自动化和优化。
该工具支持高度灵活的状态机和工作流配置，用户可以根据自己的业务需求自定义问题的处理流程。它还提供了强大的报告和分析功能，帮助团队了解项目的进展情况和性能指标。

Jira 的主要特性如下：
| 特性 | 描述 |
| ---- | ---- |
| 可定制工作流 | 允许用户根据业务需求自定义问题的处理流程 |
| 丰富的插件生态系统 | 支持与各种第三方工具集成，扩展功能 |
| 强大的报告功能 | 提供多种类型的报告，帮助团队分析项目数据 |
| 多语言支持 | 支持多种语言界面，方便全球用户使用 |

3.5.1 实践 Jira

Jira 可以选择自行安装在本地服务器，也可以使用 Atlassian 提供的云服务。如果选择云服务，只需在 Atlassian 官网注册账户并创建项目即可。
创建项目：登录 Jira 账户，点击“创建项目”，选择项目模板（如敏捷项目、经典项目等），填写项目名称和描述，点击“创建”。
创建问题：进入项目页面，点击“问题”菜单，选择“新建问题”，填写问题的详细信息，如标题、描述、优先级、经办人等，点击“创建”。
配置工作流：在项目设置中，可以自定义问题的工作流。例如，添加新的状态、设置状态之间的转换规则等。
生成报告：在项目页面的“报告”菜单中，可以选择不同类型的报告，如燃尽图、累积流图等，以分析项目的进度和性能。

以下是 Jira 工作流配置的 mermaid 流程图示例：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([待处理]):::startend --> B(处理中):::process
    B --> C(已解决):::process
    C --> D(已关闭):::startend
    B --> E(暂停):::process
    E --> B

4. 问题跟踪器的选择建议

在选择问题跟踪器时，需要综合考虑多个因素，以下是一些具体的选择建议：

4.1 根据团队规模选择

小型团队（少于 20 人）：可以选择一些轻量级、易于上手的问题跟踪器，如 Trac 或 GitLab 跟踪器。这些工具操作简单，能够满足基本的问题跟踪和协作需求，而且成本较低。
中型团队（20 - 100 人）：Redmine 或 Jira 是比较合适的选择。它们具有丰富的功能和良好的可扩展性，能够支持团队的业务增长和多样化需求。
大型团队（超过 100 人）：Jira 可能是最佳选择，其强大的定制能力和企业级的性能可以应对大规模团队的复杂工作流程和管理需求。

4.2 根据项目类型选择

软件开发项目：Bugzilla、Jira 和 GitLab 跟踪器都与软件开发流程紧密结合，能够很好地支持代码管理、缺陷跟踪和敏捷开发方法。
项目管理项目：Redmine 和 Jira 提供了全面的项目管理功能，如任务分配、进度跟踪、文档管理等，适合用于管理各种类型的项目。
开源项目：Bugzilla 和 Trac 是开源社区常用的问题跟踪工具，具有良好的社区支持和开源生态环境。

4.3 根据功能需求选择

如果需要高度可定制的工作流和状态机：Jira 无疑是首选，它可以根据业务需求进行深度定制，满足复杂的业务流程。
如果注重与代码仓库的集成：GitLab 跟踪器和 Bugzilla 具有天然的优势，能够实现代码提交与问题跟踪的无缝关联。
如果需要丰富的报告和分析功能：Jira 和 Redmine 提供了多种类型的报告和可视化工具，帮助团队了解项目的进展和性能。

5. 总结

选择合适的问题跟踪器对于团队和项目的成功至关重要。不同的问题跟踪器具有不同的特点和优势，在选择时需要充分考虑团队规模、项目类型和功能需求等因素。通过对 Bugzilla、Trac、Redmine、GitLab 跟踪器和 Jira 等工具的介绍和实践，我们可以更深入地了解它们的功能和使用方法，从而做出更明智的选择。同时，还需要注意避免问题跟踪器泛滥的问题，尽量统一团队使用的工具，以提高协作效率和组织整体效能。在实际使用过程中，要不断根据团队的反馈和业务的发展对工具进行调整和优化，确保问题跟踪器能够持续满足团队的需求。