注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ブランチ管理とリリースプロセス
このドキュメントでは、ブランチ管理の推奨ベストプラクティスと、Code Repositories 内のプロジェクトを通じて管理されるデータパイプラインのリリースプロセスの概要を説明します。
全体的な目標は、新しいデータ機能やデータ品質の修正を迅速に反復することと、安定した、所定の手順に準拠する変更管理プロセスを維持することのバランスを取るプロセスを設計することです。
リリースの範囲
リリース管理プロセスの詳細に入る前に、リリースする「製品とは何か」を正確に定義する必要があります。ここでは、product を概念上の単位としてリリースされるアセットの集合と定義します。
ここでの製品の定義には、複数のリポジトリで管理されるコードや、その他の Foundry リソースを含めることができます。
Foundry でパイプラインを構築する方法として推奨プロジェクト構成を参照すると、パイプラインは データソース、トランスフォーム、オントロジー、ワークフローという異なる種類のプロジェクトによって定義されることがわかります。ただし、ほとんどの場合、各プロジェクトを単独の製品として管理するのではなく、各プロジェクトのリソースの一部を、次のいずれかの種類の製品として定義します。
- オントロジー製品：この製品は、データソース、パイプライン、オントロジーのプロジェクトから作成される出力データセットの集合です。
- ユースケース製品：各ユースケースプロジェクトは、独立した特定のユースケースを表します。各ユースケースを製品として定義します。
製品のブランチ管理
次のセクションでは、各製品のリリースを管理するために採用するブランチ戦略について説明します。ブランチ管理の概要と、Code Repositories とデータセット間でのブランチの動作について詳しくはこちら。
製品内のすべてのリポジトリで、同じブランチ名を使用することを強く推奨します。これにより、下流のブランチが正しい上流のブランチから読み込むようになります。
推奨する基本的なブランチ戦略は、GitFlow ↗ という一般的な手法に、いくつかの変更を加えたものです。主な変更点は、release ブランチを省略することを推奨している点です。Foundry でのアーティファクトのデプロイ方法により、テスト後に dev から master へ変更を直接マージできます。
一般的なブランチ
master - 本番ブランチです。そのため、保護されたブランチであり、
このブランチへの PR のマージを承認できるのはリリースマネージャーのロールのみです。
master ブランチには、本番データが供給されることを
前提とします。
dev - dev（開発とも呼ばれる）ブランチは、
master ブランチから派生したステージング用ブランチです。主に、テストデータを使用して
機能全体をテストする場合に使用します。dev ブランチには、
master からデータを供給する（フォールバックブランチによって自動的に行われます）か、UAT データ
ソースから供給することができます。
feature-[X] - 特定の機能を開発し、
テストするための機能ブランチです。このブランチは dev ブランチから派生します。
短期間だけ使用するブランチであり、master にマージされた後は
削除できます。dev から派生しているため、
フォールバックブランチの設定が変更されず、入力データセットが機能ブランチ上に存在しない限り、
dev ブランチと同じデータが供給されます。
その他の特別なブランチ
major-release-[X] - ソースシステムのスキーマの変更（一定の周期で発生）に伴って
必要となるすべての変更を統合する特別なブランチです。
hot-fix-[X] - コードベースが新しいバージョンに移行した後に、
本番環境で見つかった問題を修正するための特別なブランチです。
dev と master は同期していることを前提としているため
（テスト中の機能がある場合を除き）、このようなブランチが必要になる可能性は低いです。
ブランチ管理のワークフロー
上記のとおり、永続的なブランチもあれば、 短期間だけ使用するブランチもあります。次のセクションでは、 ブランチ間の推奨ワークフローを説明します。
-
t0 で、
masterブランチとdevブランチを作成します。 -
t1 で、
devからfeature xブランチを作成します。 -
t2 で、
devからfeature yブランチを作成します。 -
t3 で、
feature xをdevにマージします。 -
t4 で、
devをmasterにマージし、feature xブランチを削除します。 -
t5 で、
devをfeature yにマージして、devの最新の状態を取り込みます。 -
t6 で、feature y を
devにマージし、その後、前と同じようにdevからmasterにマージします。
開発して dev と master にリリースする機能に加えて、major-release-[X] のようなメジャーリリース用の長期間使用するブランチでも開発を行います。
最新の機能を同期できるように、dev を major-release-[X] に継続的にマージすることを推奨します。オントロジーのスキーマをできる限り安定した状態に保ち、データソースとトランスフォームのプロジェクトでの変換を通じて、バックエンドのスキーマ変更を隠蔽することを推奨します。
リポジトリのアップグレード
_リポジトリのアップグレード_は、コードリポジトリ内の設定ファイルを更新するよう定期的に表示されるプロンプトです。これらの更新では、修正の適用や language-bundle の依存関係のバージョン更新が行われます。推奨されるアップグレードをこまめに適用することがベストプラクティスです。
プロンプトで「アップグレード」ボタンを選択し忘れた場合は、どのブランチでも、右上の「...」オプションメニューからこのボタンを利用できます。
アップグレードプロセスは、機能の開発サイクルと同じように扱う必要があります。具体的には、次のように行います。
-
masterはdevを通じてアップグレードします。 -
devのアップグレードを求めるプロンプトが表示されると、機能ブランチが自動的に 作成されます。CI チェックが完了したら、このブランチでビルドを実行して、設定の変更をテストできます。アップグレード後もトランスフォームが実行されることを確認したら、設定の変更をdevにマージします。devをアップグレードした後、PR を使用してこれらの変更を master に反映します。 -
すべてのオープンな機能ブランチをアップグレードするには、
devを各ブランチにマージして、これらの設定のアップグレードを取り込みます。
メンテナンスウィンドウ
アイデアから本番環境への反映までを迅速に繰り返すことは、開発では一般的な取り組みであり、エンドユーザーのフィードバックに基づいて次の反復サイクルを決めるプロジェクトの成功に不可欠です。このようなプロセスを支えるために、メンテナンスウィンドウをあらかじめ設定することを推奨します。
たとえば、すべての機能の PR をマージしたら、dev ブランチ上ですべてのデータセットをビルドし、水曜日と金曜日に結果を確認できるようにします。これらの日には、確認中に見つかった問題の修正のみを dev にマージします。その後、「リリース日」である木曜日と月曜日に、最終的に dev を master にマージします。
これらの日に新しい機能を進めるための十分な時間を確保できるよう、 関係者全員とこのような周期について合意しておくことを 推奨します。
機能のテストとエンドユーザーによる検証
機能開発が完了したら、機能の成果の正しさと、依存するリソースへの影響の両方をテストし、検証することが重要です。Code Repositories では、出力データセットを、テストすべき機能の成果とみなします。
上で定義したブランチ構造に基づくと、出力データセットをビルドする際には、機能と同じブランチにある入力データセットのデータが使用されるか、フォールバックロジックによってソースブランチから読み込まれます。ソースブランチは、簡略版では master、もう一方では dev です。
開発者レベルのテストには、データセットのヘルスチェックや依存するテストデータセットを使用するか、Contour などのツールを使って手動でテストできます。
プレビューまたは SQL ヘルパーを使ってこのテストを行うことは、強く推奨しません。プレビューヘルパーはコードの実行時にデータのサンプルのみを使用するため、すべてのケースを確認できない可能性があります。特に、1つ以上の結合操作を含むコードではその可能性があります。SQL ヘルパーはコードの正しさをテストしますが、ビルドの出力はテストしません。場合によっては、両者が異なることがあります。
機能開発が完了したら、新しい機能のコードを dev ブランチにマージする前にレビューする必要があります。また、機能の成果について、エンドユーザーが正しさと完全性を確認する必要があります。
以下の図で説明するように、前者にはプルリクエストのレビュー、後者には Foundry Issues を組み合わせて使用することを推奨します。
-
開発者は、機能ブランチから
devブランチへのプルリクエストを作成し、実装に関するコメントを追加します。 -
開発リードは PR をレビューし、必要な変更について開発者と共同作業を行い、最後に PR を
devにマージします。
プルリクエストのレビュー中は、影響を受けるデータセットのスキーマの変更を必ず確認してください。スキーマはデータ API として扱うべきものなので、列名や列のデータ型の変更は、利用者にとって「破壊的」変更とみなされます。可能な限り破壊的変更を抑えるため、既存の列を削除または変更するのではなく、新しい列を作成し、既存の列の非推奨化を告知するとともに、データ利用者（Data Connection を通じて特定）に新しい列に移行するための手順を案内します。次のメジャーリリースでは、前のメジャーリリースで非推奨となった列を削除できます。
プルリクエストでスキーマの変更をレビューするには、影響を受けるデータセットタブのスキーマ差分表示を使用します。
- 開発リードは
devブランチでビルドを実行し、機能の出力データセットを作成します。 - 開発者は出力データセットに Foundry Issue を作成し、テストおよび検証の依頼内容を記載して、検証を担当するエンドユーザーに Issue を割り当てます。
- エンドユーザーは Issue を受け取り、すべてのコンテキストと、テスト対象のデータセットおよびブランチを確認できます。必要な変更について開発者と共同作業を行い、Issue が解決され、マージ準備完了に指定されるまで対応を続けます。その後、Issue はリリースマネージャーに割り当てられます。
- リリースマネージャーは Issue をクローズし、
devをmasterにマージします。 - リリースマネージャーは機能ブランチを削除します。
上記のワークフローにより、コンテキストを失うことなく、関係者間で比較的迅速な共同作業のサイクルを実現できます。クローズされた Issue はプラットフォーム上に保持され、変更管理プロセスの監査証跡として利用できます。
Foundry Issues の機能レビューワークフロー
以下は、チームが Foundry Issues を使用して、ほかの関係者へのレビュー依頼を追跡し、新しい機能について話し合い、コードを master にマージするプロセスを管理・記録することで、関係者全員が最新の情報を把握できるようにする例です。これは厳格な規定ではなく指針として捉え、必要に応じて既存の運用プロセスや技術プロセスに合わせて調整してください。
ワークフローの例
開発者が初めて機能レビュー依頼の Issue を作成すると、Issue は Feature Review: Request Review ステータスで割り当てられます。Issue はデータセットに添付できます。また、機能が特定の列に関するものであれば、その列に添付できます。
エンドユーザーとの共同作業は、コメントセクションを通じて行い、ステータスを変更をリクエストまたはマージ準備完了に切り替え、Issue の担当者を変更しながら進めます。
Issues は、機能レビューワークフローを記録するのに適した場所です。エンドユーザーも、検証プロセスを（監査目的で）記録し、ほかのアセットへのリンクを添付できます。
以下の図は、ビルドの出力データセットに Issue を作成する方法を示しています。
-
Foundry Explorer で、出力データセットを選択します。
-
Issue を報告するをクリックして、データセット全体について Issue を報告します。
-
機能が特定の列に関係する場合は、列レベルで Issue を報告することで、レビュー担当者が変更内容のコンテキストをより把握しやすくなります。
-
フォームの案内に従って、Issue の項目を入力します。
-
Issue を作成したら、必ずラベルを
Feature Review: Request Reviewに変更してください。（これらのラベルを利用できない場合は、Palantir の担当者にお問い合わせください。）
レビュープロセスが進むにつれて、すべてのステータス変更と検証の証拠を含む共同作業のスレッドが Issue に保存されます。
