破坏构建：它是什么、原因以及如何在项目中避免

开发中破坏构建是什么意思

破坏构建是指在引入更改后项目无法再构建的情况。在 CI/CD 上下文中，这意味着构建管道以错误终止，产物无法创建。

在移动和 Web 开发领域，构建是将源代码转换为可执行文件或包的过程。对于 Android，是通过 Gradle 构建 APK 或 AAB；对于 iOS，是通过 Xcode 编译；对于 Web 项目，是通过 Webpack 或 Vite 构建。在这些阶段的任何一个都可能破坏构建。

现代版本控制系统和 CI/CD 工具，如 Jenkins、GitHub Actions 和 GitLab CI，会自动检测破坏的构建并通知团队。在大多数项目中都有规则：如果构建被破坏，其他所有任务的优先级都会降低，直到构建被修复。

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // 这一行会破坏构建
    val number: Int = "not a number"
}

在这个示例中，将字符串赋值给 Int 类型的变量会引起编译错误。类型不匹配是静态类型语言中构建破坏的最常见原因之一。

构建失败的主要原因

有几类错误会导致构建破坏。根据 GitLab 2024 年的分析，原因的分布如下。

最阴险的类别是依赖问题。更新一个模块中的库可能会破坏相邻模块的构建，如果 API 或方法的行为发生了变化。

而语法错误则可以快速检测——编译器会指明确切的行和错误类型。因此，静态类型语言在构建稳定性方面被认为比动态类型语言更可靠。

破坏的构建如何影响团队

破坏的构建直接影响团队的生产力。当构建失败时，开发人员无法从仓库获取项目的当前版本，CI 管道将被阻止所有后续的更改。

Atlassian 2023 年的研究表明，构建破坏超过四个小时的项目平均会损失团队 25% 的有效工作时间。开发人员被迫把精力放在问题诊断上，而非执行自己的任务。

除了生产力，团队士气也会受到影响。破坏构建的开发人员会感受到同事的压力。在健康的团队中，规则是：不因构建破坏而惩罚，但要求立即修复。无责文化 — 将事故作为系统性问题而非某人的错误来分析的方法。

在分布式团队中，破坏的构建可能会阻止其他时区员工的工作。如果欧洲的开发人员在下班前破坏了构建，亚洲的团队可能会因等待修复而损失整个工作日。

如何预防破坏构建

预防构建破坏从提交前的本地检查开始。每位开发人员应该在提交更改前运行测试和构建。主要的预防方法分为几个层级。

• Pre-commit 钩子 — 在创建提交前自动检查，包括 lint 工具和格式化工具
• 本地构建 — 在推送前运行编译，尤其是对于静态类型语言
• 单元测试 — 用测试覆盖关键模块，以便早期发现回归
• 代码审查 — 在合并到主分支前由同事审查更改

第二个层级是配置 CI/CD 管道。每个拉取请求必须在合并前通过自动构建和测试。如果构建失败，PR 将被阻止直到修复。这种方法称为 守门提交，在大多数现代项目中使用。

第三个层级是监控和统计。团队跟踪构建恢复时间指标——MTTR（平均恢复时间）。该指标越低，团队对构建破坏的反应越快。目标值不超过 30 分钟。

构建破坏后该怎么办

当构建被破坏时，第一步是确定哪位开发人员最后引入了更改。Git 提供了 git bisect 工具，可以通过二分搜索找到破坏构建的提交。

# 使用已知的好和坏提交开始二分查找
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git 检查中间的一个提交
# 构建并测试，然后标记：
git bisect good  # if build passes
git bisect bad   # if build fails

# 约 log2(n) 步后，Git 显示罪魁祸首
git bisect reset

找到问题提交后，有两种操作可选。第一种是通过 git revert 回退更改，如果修复需要时间。这是最安全的方法，尤其是当构建阻止了整个团队时。

第二种方案是用新提交立即修复。如果问题是局部的且清楚的，则优先采用这种方法。修复后推送更改并确保构建成功。无论如何，构建恢复时间不应超过一个小时。