设计和实现源、bug 和质量可追溯性

  • 3 分钟

在 DevOps 的上下文中，可跟踪性是指跟踪整个软件开发生命周期中的更改和操作的能力。 此概念适用于该生命周期的不同方面，包括对源代码的更改、bug 解决和维护质量控制。 要确保产品可靠性、可维护性和客户满意度，它的实现至关重要。

利用源可跟踪性，开发人员可以在协作场景中跟踪代码更改。 Bug 可跟踪性有助于识别、确定优先级并解决源代码问题。 质量可跟踪性通过将测试活动、指标和反馈与开发工作联系起来，确保软件满足质量标准和用户期望。

设计

概括而言，可跟踪性与工具无关，但实现它的方法取决于它所针对的软件开发生命周期方面。 同样，源代码、bug 和质量可跟踪性之间的目标和设计注意事项也不同。

特别是，源可跟踪性涉及跟踪代码更改的历史记录，包括谁进行了更改、何时进行了更改以及更改的目的。 它有助于代码评审、调试和了解代码库随时间推移的演变。 从设计的角度来看，此功能与组织开发工作的 Git 分支和合并策略密切相关。 开发人员为新工作创建功能分支，提交对其分支的更改，并提交拉取请求以供审阅。 此时，其对等项进行代码评审，一旦成功完成，就批准将更改合并到主分支中。

Bug 可跟踪性涉及跟踪在测试或生产过程中报告的 bug 或缺陷，直到在代码库中找到根本原因。 它还通常依赖于捕获信息，例如 Bug 报告详细信息、重现步骤、受影响的组件和相关代码更改。 其目标包括有效地确定 bug 的优先级和解决 bug，以解决软件缺陷。

质量可跟踪性包括在整个软件开发过程中跟踪与质量相关的活动和项目。 这包括将质量指标、测试用例、测试结果和其他质量保证活动与要求、用户情景和代码更改联系起来。 质量可跟踪性有助于评估软件更改对其质量的影响，并确定改进方面。

实现可跟踪性

根据 DevOps 平台，可跟踪性实现细节在一定程度上有所不同。

源可跟踪性

由于 GitHub 和 Azure DevOps 都支持 Git 作为其源代码管理机制，因此许多源可跟踪性技术适用于这两者。 因此，在这两种情况下实现源代码可跟踪性涉及到采用最佳做法，例如编写描述性提交消息、使用明确定义的分支策略，以及要求进行代码评审的拉取请求。

但是，这两者也存在一些差异。 在 GitHub 存储库中实现源可跟踪性通常涉及利用分支保护规则等功能来强制实施代码评审过程，并确保在合并之前查看更改。 通过 GitHub 与问题的集成，可将代码更改与相应的问题相关联，从而在代码修改和项目要求之间提供可跟踪性。 Azure DevOps 提供分支策略和拉取请求策略，用于强制实施代码质量检查并将更改关联到工作项，从而在代码更改和用户情景/任务之间实现可跟踪性。 此外，Azure DevOps 提供与其工作项跟踪系统更广泛的集成，这样与 GitHub 的问题跟踪相比，可实现更深入的可跟踪性和报告功能。

Bug 可跟踪性

在 Azure DevOps 中，Bug 可跟踪性通过 Azure Boards 得到促进，其中 Bug 可作为工作项进行跟踪，并且可关联到代码更改、提交和拉取请求。 通过 Azure Boards 可为 Bug 管理创建自定义工作流，定义“新”、“活动”、“已解决”和“已关闭”等状态，从而提供 Bug 生命周期的可见性。 此外，Azure DevOps 提供 Bug 和其他工作项之间的丰富集成，从而在 Bug 与用户情景、任务和长篇故事之间实现可跟踪性。

在 GitHub 中，Bug 可跟踪性依赖于问题与代码更改之间的集成，其中报告为问题的 Bug 可以关联到提交和拉取请求。 通过 GitHub Actions 可实现可自定义工作流，包括与 Bug 可跟踪性相关的工作流。 使用 GitHub Actions，可定义工作流，以自动执行 GitHub 存储库中的事件触发的进程，例如创建或修改问题。 这样，就可以创建自定义工作流来管理 Bug，包括定义状态、分配任务和基于特定条件自动执行操作。 实际上，尽管 GitHub Actions 在工作流自动化方面提供了灵活性，但与 Azure DevOps 中 Azure Boards 的内置功能相比，它们通常需要更多工作和自定义。

质量可跟踪性

在 Azure DevOps 中，可以使用测试计划管理质量可跟踪性，使团队能够组织、执行和跟踪测试用例。 测试计划提供全面的质量指标，包括测试用例通过率、测试运行结果和测试覆盖率报告。 此外，Azure DevOps 还提供与代码覆盖率工具的集成，可测量测试覆盖率并确定需要额外测试的代码库区域。

GitHub 通过 GitHub Actions 提供类似的功能，使团队能够自动执行各种类型的测试，例如单元测试、集成测试和端到端测试。 此外，GitHub Actions 还可以灵活地设置测试工作流并与第三方测试工具集成，但它们往往需要其他配置才能实现与 Azure DevOps 测试计划相同级别的全面质量指标和测试覆盖率报告。