ビルドを壊す：その概要、原因、プロジェクトでの回避方法

開発におけるビルドを壊すとは

ビルドを壊すとは、変更を加えた後にプロジェクトがビルドできなくなる状況です。CI/CDの文脈では、ビルドパイプラインが失敗し、アーティファクトが作成されないことを意味します。

モバイル・ウェブ開発の世界では、ビルドとはソースコードを実行可能なファイルやパッケージに翻訳するプロセスです。Androidの場合は、Gradleを使用してAPKやAABを構築します。iOSの場合は、Xcodeを通じてコンパイルします。ウェブプロジェクトの場合は、WebpackやViteを通じてバンドルします。これらのいずれのステージでもビルドを壊す可能性があります。

現代のバージョン管理システムやJenkins、GitHub Actions、GitLab CIなどのCI/CDツールは、自動的に壊れたビルドを検出し、チームに通知します。ほとんどのプロジェクトでは、ビルドが壊れた場合、ビルドが修正されるまで他のすべてのタスクの優先度が下げられるというルールがあります。

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // この行はビルドを壊す
    val number: Int = "not a number"
}

この例では、Int型の変数に文字列を代入するとコンパイルエラーが発生します。型の不一致は静的型チェック言語におけるビルド破損の最もよくある原因の一つです。

ビルド失敗の主な原因

壊れたビルドにつながるエラーはいくつかのカテゴリに分類できます。2024年のGitLabの分析によると、原因の分布は以下の通りです。

最も注意が必要なのが依存関係の問題です。あるモジュールでライブラリを更新すると、APIやメソッドの動作が変わった場合に隣のモジュールでビルドが壊れる可能性があります。

一方で文法エラーはより早く検出できます。コンパイラが正確な行とエラー型を指示します。これが、静的型チェック言語が動的型チェック言語よりもビルドの安定性において信頼性が高いと考えられる理由です。

壊れたビルドがチームに与える影響

壊れたビルドはチームの産性に直接影響します。ビルドが失敗すると、開発者はリポジトリからプロジェクトの最新バージョンを取得できなくなり、CIパイプラインもその後のすべての変更に対してブロックされます。

Atlassianの2023年の研究によると、ビルドが4時間以上続けて壊れたままのプロジェクトは、チームの生産性の平均25%を失うことがわかりました。開発者は自分のタスクを完了する代わりに問題の診断に注意を向ける必要があります。

生産性だけでなく、チーム内の士気も受ける影響も大きいです。ビルドを壊した開発者は同料からの圧力を感じます。健全なチームでは、壊れたビルドに対して罰せるのではなく、即座の修正を要求するルールが守られています。ブレームレス・カルチャーとは、インシデントを誰かの間違いとしてではなく、システム的な問題として分析するアプローチです。

分散チームでは、壊れたビルドが別の時間帯の同料の作業をブロックする可能性があります。ヨーロッパの開発者が帰る前にビルドを壊した場合、アジアのチームは修正を待つ間に一日分の作業を失う可能性があります。

壊れたビルドを防ぐ方法

壊れたビルドの予防は、コミット前のローカル検査から始まります。各開発者は変更をプッシュする前にテストとビルドを実行する必要があります。主な予防方法はいくつかの階層に分けられています。

• pre-commitフック — リンターやフォーマッターを含む、コミット作成前の自動検査
• ローカルビルド — 特に静的型チェック言語では、プッシュ前にコンパイルを実行
• 単体テスト — 変更を早期に検出するために重要なモジュールをテストでカバー
• コードレビュー — メインブランチにマージする前に同料が変更をレビュー

第2の階層はCI/CDパイプラインの構成です。各プルリクエストはマージ前に自動的なビルドとテストを通過する必要があります。ビルドが失敗すると、PRは修正されるまでブロックされます。このアプローチはゲーテッド・コミットと呼ばれ、ほとんどの現代的なプロジェクトで使用されています。

第3の階層はモニタリングと統計です。チームはMTTR（平均修理時間）メトリックを追跡します。この指標が低いほど、チームは壊れたビルドに対して早く対処できます。目標値は30分以内です。

ビルドが壊れた場合の対処法

ビルドが壊れた場合、最初のステップはどの開発者が最後に変更を行ったかを特定することです。Gitはgit bisectというツールを提供しており、二分探索によってビルドを壊したコミットを見つけることができます。

# 己知の良いコミットと悪いコミットで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

問題のコミットを見つけた後は、2つの対処方法があります。1つ目は、修正に時間がかかる場合はgit revertを使用して変更を戻す方法です。これは特にビルドがチーム全体をブロックしている場合に最も安全です。

2つ目は、新しいコミットを作成して即座に修正する方法です。この方法は、問題が局所的で明確な場合に適しています。修正後に変更をプッシュし、ビルドが成功することを確認します。いずれの場合でも、ビルドの回復時間は1時間を超えてはなりません。