> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 差分ビルド

> 変更があったブループリントのワークスペースだけを再ビルドして、スナップショットのビルドを高速化します。変更のないワークスペースは、前回正常に完了したビルドから引き継がれます。

<div id="overview">
  ## 概要
</div>

デフォルトでは、すべてのスナップショットのビルドは **フルビルド** です。クリーンなベースイメージから開始し、すべてのリポジトリをクローンして、すべてのブループリントを毎回最初から実行します。これにより、環境を完全に再現可能にできますが、多数あるブループリントのうち 1 つだけを変更した場合でも時間がかかることがあります。

**差分ビルド** は、前回成功したビルドのスナップショットを開始点として再利用することで、これを最適化します。実際にブループリントが変更されたワークスペースだけを再ビルドし、変更されていないワークスペースは親ビルドからそのまま引き継ぎます。これにより、特に多数のリポジトリを持つ組織では、ビルド時間を大幅に短縮できます。

<div id="enabling-differential-builds">
  ## 差分ビルドを有効にする
</div>

<Steps>
  <Step title="Environment の設定に移動する">
    **Settings > Environment > Advanced** に移動します。
  </Step>

  <Step title="トグルを有効にする">
    **Differential builds** のトグルをオンにします。説明には次のように表示されます: *"変更のないワークスペースを再利用することで、ビルドを高速化します。"*
  </Step>

  <Step title="ビルドをトリガーする">
    ブループリントの変更を保存するか、**Build snapshot** をクリックします。有効な親ビルドが存在する場合、次回のビルドでは差分ビルドの実行が試行されます。
  </Step>
</Steps>

<Warning>
  差分ビルドを有効にした直後の最初のビルドは、必ず **フルビルド** になります。これは、比較対象として正常に作成されたベースラインスナップショットが必要なためです。それ以降のビルドは、有効な親が存在する限り差分ビルドになります。
</Warning>

<div id="how-it-works">
  ## 仕組み
</div>

差分ビルドを有効にした状態でビルドがトリガーされると、システムは次の手順で処理を行います:

<div id="1-find-a-parent-build">
  ### 1. 親ビルドを見つける
</div>

システムは、親として利用する直近の成功ビルド (status が `success` または `partial`) を探します。条件を満たす親がない場合、ビルドは自動的にフルビルドに切り替わります。

<div id="2-compare-blueprints">
  ### 2. ブループリントを比較する
</div>

各ワークスペースの構成は親ビルドと比較されます。システムは、ブループリントの内容、アタッチされたファイル、シークレット、リポジトリの順序などを含む各ワークスペースの入力のダイジェストを計算し、変更点を確認します。

<div id="3-assign-workspace-actions">
  ### 3. ワークスペースのアクションを割り当てる
</div>

比較結果に基づいて、各ワークスペースには次の 3 つのアクションのいずれかが割り当てられます。

| Action      | 内容                                                                | 使用するタイミング                        |
| ----------- | ----------------------------------------------------------------- | -------------------------------- |
| **Rebuild** | リポジトリをクローンし、すべてのブループリントのステップ (initialize + maintenance) を最初から実行する | 親のビルド以降にブループリントが変更された場合          |
| **Inherit** | 最新のコードを取得し、`maintenance` ステップのみを実行する                              | ブループリントに変更がない場合 — 親のセットアップを再利用する |
| **Remove**  | スナップショットからワークスペースを削除する                                            | ワークスペースが構成から削除された場合              |

<Info>
  継承されたワークスペースでは、`initialize` は再実行されません。`maintenance` は、
  最新のコードを取得したあとでも単独で実行できるよう、自己完結した形で記述してください。
  親のスナップショットにすでにインストールされているツールやランタイムは利用できますが、
  その直前に `initialize` が実行されていることを前提にしたり、以前 `initialize` が
  `$ENVRC` に書き込んだ環境変数に依存したりしてはいけません。
</Info>

<div id="4-execute-the-build">
  ### 4. ビルドを実行する
</div>

このビルドはクリーンなベースではなく、親ビルドのスナップショットイメージを基に開始されます。つまり、次のようになります。

* **継承されたワークスペース** では、必要なツール、ランタイム、依存関係はすでにインストールされています。システムは最新のコードを取得し (`git pull`) 、依存関係を更新するために `maintenance` コマンドを実行します。
* **再ビルドされるワークスペース** は最初からセットアップされ、新たにクローンされたうえで、`initialize` + `maintenance` の一連の処理がすべて実行されます。
* **削除されたワークスペース** では、対応するディレクトリがクリーンアップされます。

組織ブループリントとEnterpriseブループリントでは、差分ビルド中は `initialize` をスキップし (それらのツールはすでに親イメージに含まれているため) 、`maintenance` のみを実行します。

<Note>
  `$ENVRC` は、差分ビルドを含むすべてのビルドの開始時にリセットされます。
  以前のビルドで `$ENVRC` に書き込まれた環境変数や `PATH`
  エントリは引き継がれません。`maintenance` でそれらが必要な場合は、
  `maintenance` 側で設定する必要があります。
</Note>

<div id="when-a-full-build-runs-instead">
  ## フルビルドが実行されるケース
</div>

差分ビルドが有効でも、次のような場合はシステムがフルビルドにフォールバックします。

* **親ビルドが存在しない** — 初回ビルドであるか、過去のビルドがすべて失敗している
* **組織またはEnterpriseブループリントが変更された** — グローバルな変更はすべてのワークスペースに影響するため、クリーンな再ビルドのほうが安全です
* **リポジトリの順序が変更された** — リポジトリ同士でセットアップに依存関係がある場合があるため、順序を変更するとフル再ビルドがトリガーされます
* **親ビルドが古すぎる、または互換性がない** — システムは親ビルドが適切かどうかを検証します

フォールバックが発生すると、ビルド詳細ページのビルド種別バッジの下にその理由が表示されます。

<div id="viewing-build-kind">
  ## build の種類を確認する
</div>

build が完了すると、それが differential build と full build のどちらとして実行されたかを確認できます。

1. **Settings > Environment > Snapshots** に移動します
2. 履歴内の build をクリックします
3. **Build kind** バッジに **Differential** (青) または **Full build** (デフォルト) が表示されます

バッジにカーソルを合わせると、各種類の意味を説明するツールチップが表示されます。

* **Differential**: *「変更されたワークスペースのみが再ビルドされ、変更されていないものは同じ設定で最後に成功した build から引き継がれます」*
* **Full build**: *「すべてのワークスペースが最初からビルドされます」*

<div id="benefits">
  ## 利点
</div>

| 利点               | 説明                                                                           |
| ---------------- | ---------------------------------------------------------------------------- |
| **ビルドの高速化**      | 変更されたワークスペースのみが完全なセットアップ処理の対象になります。継承されたワークスペースでは、`initialize` は完全にスキップされます。 |
| **ネットワーク使用量の削減** | 変更のないワークスペースでは、ツール、ランタイム、大容量の依存関係を再ダウンロードする必要がありません。                         |
| **反復作業の高速化**     | 1 つのリポジトリのブループリントを繰り返し調整しても、ほかのリポジトリがビルドの足かせになることはありません。                     |
| **同等の信頼性**       | 問題があると判断された場合、システムは自動的にフルビルドにフォールバックします。必要に応じて、いつでも手動でフルビルドをトリガーすることもできます。   |

<div id="manually-triggering-a-full-build">
  ## フルビルドを手動でトリガーする
</div>

差分ビルドが有効になっている場合でも、**Build snapshot**ボタンからフルビルドを強制できます。ドロップダウンで、デフォルトの差分オプションではなく**Full build**を選択してください。

継承された状態を破棄し、ブループリントで引き続き環境をゼロから作成できることを確認するため、定期的にフルビルドを実行することを推奨します。また、スナップショット内に滞留したファイル、ツール、依存関係が残っている可能性のあるセットアップを削除または置き換えた後にも実行してください。フルビルドでは、すべての`initialize`ステップと`maintenance`ステップが再実行されます。

<div id="faq">
  ## よくある質問
</div>

<AccordionGroup>
  <Accordion title="差分ビルドを有効にすると、セッションに影響しますか？">
    いいえ。セッションはビルド方法にかかわらず、常に最終スナップショットから起動します。違いはビルド速度だけです。
  </Accordion>

  <Accordion title="差分ビルドで問題のあるスナップショットが生成された場合はどうなりますか？">
    **Settings > Environment > Snapshots** で以前の正常なビルドをピン留めし、その後フルビルドをトリガーしてクリーンなスナップショットを取得してください。差分ビルドを完全に無効にして、フルビルドに戻すこともできます。
  </Accordion>

  <Accordion title="部分ビルドは親として扱われますか？">
    はい。ステータスが `partial` のビルド (一部のワークスペースは成功し、一部は失敗した状態) も親として使用できます。親で成功したワークスペースからのみ継承されます。
  </Accordion>
</AccordionGroup>