ブランチ

ソフトウェア開発者は通常、バージョン管理システムを使ってコードベース内の作業を調整します。これにより、複数のエンジニアが同じコードに安全に変更を加えられます。

Foundry では、ソフトウェア開発者がコードを扱うのと同じようにデータを扱います。多くの人が、ほかの人の作業を妨げることなく、同じデータに変更を加えたり、操作したりできる仕組みが必要です。そこで、ソフトウェア開発のベストプラクティスをデータパイプラインの作成に適用し、バージョン管理システムで一般的なブランチという機能を活用しています。

大まかに言うと、ブランチを使うと、メインの経路から分岐して、自分のブランチでデータを扱えます。その後、変更内容に満足したら、このブランチからメインの経路に変更を戻せます。

ブランチのワークフロー

ブランチのワークフローを使って Foundry のデータパイプラインコードを変更する方法は次のとおりです。

1. ブランチを作成する。Foundry では、master ブランチは主要なデータパイプラインを指します。独自の変更に取り組む場合は、自分のブランチを作成します。これにより、master ブランチへの影響を心配せずに、実験やアイデアの検証ができる環境が作成されます。
2. コミットを作成する。このブランチ内で、データ変換に変更を加えられます。追加や削除を含む変更をコミットと呼びます。コミットは追跡されるため、このブランチで行ったすべての変更の履歴が明確に残ります。
3. プルリクエストを作成する。独立した環境での作業が完了したら、変更を master ブランチに戻します。このプロセスを開始するには、プルリクエストを作成します。プルリクエストは、master データパイプラインに反映するために、レビューと検証を依頼したい変更を加えたことをチームに知らせます。
4. コードをレビューする。プルリクエストを作成すると、チームがコミットをレビューできるようになります。プルリクエストをレビューするプロセスや担当チームは、組織によって異なります。

Foundry のブランチ機能は、業界標準の Git に似たバージョン管理の仕組みを実装しています。そのため、Code Repositories アプリケーションは、ファイルの個々のブランチで作業する開発者が1人であることを前提に設計されています。ほかのユーザーが**personal ブランチ**で作業している場合、変更が上書きされる可能性があります。これを避けるため、各ユーザーが別々のブランチで作業することを強く推奨します。

このページの以降のセクションでは、Foundry におけるブランチの仕組みの技術的な詳細を説明します。ブランチの実際の使い方を学ぶには、Pipeline Builder または Code Repositories でシンプルなバッチパイプラインを作成するチュートリアルに沿って進めてください。

ブランチの技術的な詳細

Foundry では、データのブランチ機能は、個々のデータセット内のブランチと、データセットのビルド時のブランチという、2つの異なるレベルの機能を使って実装されています。

データセットのブランチ

データセットのページで説明したように、データセットには一連のトランザクションという形式でバージョン履歴が保存されます。概念的には、データセットのブランチは Git のブランチに似ており、データセット、ブランチ、トランザクションは、それぞれ Git のリポジトリ、ブランチ、コミットに相当します。

Git のブランチと同様に、データセットのブランチは、そのブランチ上の最新のトランザクションへのポインターにすぎません。そのため、ブランチはコミット時刻順に並んだトランザクションの直線的な列として捉えられます。トランザクションをコミットしてブランチ上のデータセットを変更しても、ほかのすべてのブランチのトランザクションとビューは変更されません。Git とは異なり、データセットのブランチのマージはサポートされていません。

各データセットのブランチには、ルートブランチでない限り、親ブランチが必ず1つあります。実際には、Foundry のほとんどのデータセットには master という名前のルートブランチが1つあり、このルートブランチから子ブランチが作成されます。

データセットのブランチに関してサポートされている操作は、以下のとおりです。

• 新しいブランチを作成する。親ブランチもトランザクションもないルートブランチを作成できます。
• 子ブランチを作成する。子ブランチは、別のブランチから、または任意のトランザクションから作成できます。新しいブランチは、親ブランチと同じトランザクションを指します。その後、親ブランチと子ブランチの両方でトランザクションを開始でき、それぞれのトランザクションポインターは独立して移動します。
• ブランチ上で新しいトランザクションを開始する。トランザクションを開始し、ブランチポインターを新しいトランザクションに移動します。
• ブランチを削除する。ブランチポインターを削除しますが、ブランチ上のトランザクションは削除しません。以下の保証事項にある親ブランチについての説明を参照してください。

データセットのブランチの保証事項

Foundry は、データセットのブランチについて次の事項を保証します。

• 各ブランチで開いているトランザクションは最大1つ。各ブランチで開いている（開始済みで、コミットも中止もされていない）トランザクションは最大1つであり、このトランザクションは常にそのブランチ上の最新のトランザクションです。したがって、ブランチが1つのデータセットでは、開いているトランザクションは最大1つです。ブランチが開いているトランザクションを指している場合、このブランチから新しいブランチを作成できますが、そのトランザクションが閉じられるまで、それ以上のトランザクションは開始できません。
• 各ブランチ上で、トランザクションは開始時刻とコミット時刻の順に並ぶ。この保証は、前述の制約によるものです。ただし、異なるブランチ上のトランザクション間の時間的な順序については、保証されません。
• ルート以外の各ブランチには親ブランチが必ず1つある。「中間」ブランチ、つまり子ブランチを持つブランチが削除された場合、子ブランチの親は、削除されたブランチの親に変更されます（削除されたブランチがルートブランチだった場合は、親がなくなります）。この処理でトランザクションが並べ替えられることはありません。親の変更は、ブランチの祖先関係の記録を変更するだけです。

ビルドにおけるブランチ

データセットのブランチ機能は、データのバージョン管理の基盤となるセマンティクスを提供します。Foundry はデータセットのブランチ機能と Git のブランチ機能を組み合わせることで、ロジックとデータを同時にブランチ化できるようにします。これにより、データエンジニアはデータパイプラインへの変更を本番環境に導入する前に、安全に試すことができます。

Git のロジックのブランチとデータセットのデータのブランチは、Foundry のビルドシステムを通じて結び付けられます。すべてのビルドはユーザーが指定したブランチで実行され、ビルド内のジョブはそのブランチ上のデータセットのみを変更します。そのため、ビルドにおけるブランチを使うことで、ユーザーごとの変更を互いに分離できます。

Foundry のビルドは、ブランチに関して次の2つの主な機能を実行します。

• まず、適切なブランチからジョブ仕様（Job Spec）を収集して、ビルドグラフをコンパイルします。
• 次に、ユーザーが定義したビルドブランチと一連のフォールバックブランチに基づいて、ジョブの入力と出力を解決します。

ジョブグラフのコンパイル

Foundry でコードリポジトリのブランチにデータ変換を記述し、コードをコミットすると、ビルドシステムの適切なブランチに Job Spec が公開されます。そのブランチでビルドを実行すると、ビルドはこのブランチの Job Spec とその依存関係をたどり、実行すべきロジックを特定します。

通常、ビルドにはブランチフォールバックが指定されます。これは、ビルドブランチに Job Spec が設定されていない場合に、どのブランチから Job Spec を取得するかを決めるものです。たとえば、develop --> master というフォールバックチェーンを使って develop でビルドを実行した場合、ある出力データセットの Job Spec が公開されていなければ、代わりに master ブランチから Job Spec が読み取られます。

データセットのアイコンの色は、Job Spec とブランチに関する情報を示します。データセットのアイコンが灰色の場合、master ブランチに Job Spec が存在しないことを示します。データセットのアイコンが青色の場合、master ブランチに Job Spec が定義されています。

入力と出力の解決

ビルド内の Job Spec で出力として指定されたすべてのデータセットでは、ビルドブランチでトランザクションが開かれます。データセットにこのブランチが存在しない場合は、フォールバックチェーンの最初のブランチから作成されます。フォールバックブランチが存在しない場合は、ルートブランチとして作成されます。ジョブの入力は、可能であればビルドブランチから読み取られます。それ以外の場合は、フォールバックチェーン内で最初に存在するブランチが使用されます。

例：ブランチでビルドする

ビルドでのブランチの動作を理解するために、ワークフローの例を順に見ていきます。

1. データセット A、B、C が master ブランチに存在するとします。
2. データエンジニアがコードリポジトリで feature という名前のブランチを作成します。これにより、基盤となる Git リポジトリにブランチが作成されます。
3. データエンジニアが、データセット B と C を生成するコードを変更します。コードをコミットすると、リポジトリのチェックによって、feature ブランチ上の両方のデータセットに Job Spec が公開されます。
4. データエンジニアが feature ブランチでビルドを開始します。feature ブランチは Git リポジトリの master ブランチから作成されたため、このビルドのフォールバックチェーンは feature --> master となります。ステップ（3）で公開された Job Spec が読み取られ、ユーザーのコードに対応する2つのジョブが開始されます。feature ブランチ上のデータセット B と C の両方でトランザクションが開かれます。2つのジョブは、次のように順次実行されます。
   1. ジョブ1：ブランチフォールバックにより、データセット A の master ブランチが入力として使用されます。計算によって新しいデータが生成され、現在開いているトランザクションでデータセット B に書き込まれます。トランザクションがコミットされます。
   2. ジョブ2：次に、このジョブが開始されます。データセット B の feature ブランチが入力として使用されます。計算によって新しいデータが生成され、現在開いているトランザクションでデータセット C に書き込まれます。トランザクションがコミットされます。
5. 最後に、ビルド内のすべてのジョブが成功したため、ビルドに成功します。

コードを変更してコミットし、ビルドを実行したことで、データエンジニアはデータセット B と C の feature ブランチに新しいデータを生成しました。このプロセスによってデータセット A はまったく影響を受けず、データセット B と C の master ブランチも変更されていないことに注目してください。

ビルドブランチの保証

Foundry のビルドは、ブランチについて次のことを保証します。

• ビルドの解決は、指定されたブランチフォールバックの順序が、対象データセットのブランチの祖先関係に対応している場合にのみ成功します。
• ビルドが、ビルドブランチ以外のデータセットブランチを変更することはありません。
• ビルドが入力データセットにブランチを作成することはありません。