バージョン管理によるプロジェクトの管理
バージョン管理を使用して、データプロジェクトの開発を管理し、変更点を追跡できます。
バージョン管理を使用する場合、設計中にプロジェクトのバージョンをコミットできます。これにより、プロジェクトの 2 つのバージョン間の変更を確認できます。ブランチ戦略を使用して、データ プロジェクトを開発することもできます。これにより、各作業エリアまたはブランチで、プロジェクトの分離されたバージョンで作業できるようになります。作業エリアは複数のユーザーで共有できます。その後、作業エリアからメイン ブランチに変更をマージして、本番環境に展開できます。
バージョン管理のプロバイダーとして GitHub を使用しています。
はじめに
-
テナントが GitHub にアクセスするためのユーザーを GitHub に作成します。管理者によってユーザーがすでに作成されている場合があります。
ユーザーには次のスコープが必要です。
-
repo
-
read:org
-
read:user
-
read:project
-
-
変更するリポジトリへの書き込み権限が必要です。
-
GitHub personal access token (classic) を作成する必要があります。Fine-grained personal access token はサポートされていません。
詳細は、GitHub のドキュメンテーションで「個人用アクセス トークンを管理する」を参照してください。
-
GitHub 構成では組織は必須です。
-
バージョン管理アクションを実行するには、プロジェクトが存在するスペースで編集できるロールが必要です。
-
バージョン管理の使用を開始する前に、作成した GitHub ユーザーで GitHub に接続するための構成を設定する必要があります。
-
GitHub への接続を設定したら、プロジェクトをリポジトリに接続できます。
GitHub への構成の設定
バージョン管理を使用するすべてのユーザーは、GitHub ユーザー アカウントを使用して GitHub に接続するための構成を設定する必要があります。
GitHub 接続

[プロジェクト] で GitHub を構成できます。はじめに に従って準備したことを確認してください。
-
をクリックし、 [GitHub 構成] クリックします。
-
組織および はじめに で説明されている GitHub personal access token を使用して認証を設定します。
-
OKをクリックします。
プロジェクトをリポジトリに接続できるようになりました。
プロジェクトをリポジトリに接続する
バージョン管理の使用を開始する前に、プロジェクトをリポジトリに接続する必要があります。GitHub への接続が設定されていることを確認してください。
プロジェクトをバージョン管理に接続します。

-
[プロジェクト] で、プロジェクトの [...] をクリックし、 [バージョン管理に接続] を選択します。
-
プロジェクトを関連付けるリポジトリを選択します。
-
ベース ディレクトリ パスを追加します。
GitHub の既存のプロジェクトに接続する場合は、同じパスを使用する必要があります。
-
接続後にプロジェクトをコミットし、リモート リポジトリにプッシュすることを選択できます。コミット メッセージを入力します。
コミットしてプッシュしない場合、作業エリアにメイン ブランチが作成されますが、リモート リポジトリには作成されません。
-
[接続] をクリックします。
プロジェクトは選択したリポジトリに接続されました。これは、プロジェクト カードの下部に 、リポジトリの名前、現在のブランチとともに示されます。
プロジェクトを開くと、タイトル行にバージョン管理オプションを含む GitHub メニューが表示されます。プロジェクト名には現在のブランチの名前も追加されます。
バージョン管理によるプロジェクトの開発
バージョン管理は、次のようなさまざまな方法で使用できます。
-
メイン ブランチでの直接作業。これは主に、プロジェクトで変更を追跡する 1 人の開発者に適していますが、同期して作業する開発者のグループでも使用できます。
-
複数の開発者が貢献できるブランチ戦略での作業。ブランチを作成して、新しい機能や変更を互いに分離することもできます。
単一開発者プロジェクト向けの簡素化されたワークフロー
プロジェクトのメイン ブランチで直接作業できます。このアプローチはよりシンプルで操作も少なくなりますが、変更を追跡することはできます。開発者が複数いる場合は、同期をとるように注意する必要があります。
適用するプロジェクトに変更を加えたら、 [コミットしてプッシュ] を実行します。
複数の開発者によるプロジェクトのワークフロー
このワークフローは、プロジェクトに複数の開発者が関わっている場合、または変更を分離する場合に使用できます。これには、他のユーザーと共有できる開発ブランチの作成が含まれます。このワークフローにより、開発者は互いの変更を追跡し、変更をメイン ブランチにマージするタイミングを決定できます。
バージョン管理を使用した複数の開発者によるプロジェクトのワークフロー

-
新しいブランチの作成
メイン ブランチから新しい開発ブランチを作成します。ブランチをより多くのユーザーと共有できます。
-
開発
プロジェクトで必要な変更をすべて実行します。
情報メモデータベース スキーマと接続は、バージョン管理では維持されません。 -
リモートの変更を適用
他のブランチからのリモート変更を自分の作業エリアに適用し、他のブランチからの変更に対応できるようにします。これは、競合する変更を回避または軽減するのに役立ちます。
競合する可能性のある変更を含む 2 つのブランチがある場合、回避策は次のとおりです。
-
両方の作業エリアに変更をコミットします。
-
両方のブランチをメインにマージします。
-
リモートの変更を再度適用します。
-
-
コミットしてプッシュ
変更を開発ブランチにコミットしてプッシュします。すべてのオブジェクトがプッシュされるため、コミットする前にプロジェクトを検証することをお勧めします。
-
プル リクエストを開いてマージする
開発の準備ができたら、作業エリアからメイン ブランチに変更をマージします。開発ブランチをメイン ブランチにマージするには、GitHub でプルリクエストを開いて実行する必要があります。メイン ブランチにマージするブランチの承認を設定できます。詳細については、「GitHub プルリクエストのドキュメント」を参照してください。
新しいブランチを作成
-
[プロジェクト] で、プロジェクトの [...] をクリックし、 [新しいブランチを作成] を選択します。
プロジェクトはバージョン管理に接続されている必要があります。プロジェクトのターゲット接続が存在するスペースに対する権限も必要です。
-
メイン ブランチからブランチを作成する場合に選択します。
-
ブランチの名前を入力します。
-
[すべてのスキーマのブランチ プレフィックス] で、プロジェクト内のすべてのスキーマに追加するプレフィックスを設定します。こうすることで、すべてのスキーマに一意の名前を付けることができ、名前の競合を回避できます。
-
[作成] をクリックします
メインから新しいブランチが作成され、リポジトリからチェックアウトされます。ブランチにはプロジェクトの新しいバージョンが含まれており、すべてのタスクのステータスは 「新規」になります。つまり、準備されておらず、データが含まれていません。
リモート変更の適用
リモート リポジトリからの変更を作業エリアに適用できます。これは、たとえば GitHub や他のツールなど、Qlik Cloud 統合バージョン管理の外部で作成された変更である可能性があります。これにより、変更をブランチにコミットしてプッシュするときに競合を回避できます。
-
[プロジェクト] で、プロジェクトの [...] をクリックし、 [リモートの変更を適用] を選択します。
変更が見つかった場合は、 [作業エリアにリモートの変更を適用] ダイアログが表示されます。
-
変更を適用するタスクを選択し、変更を検査できるようになりました。変更ごとに、リモート バージョンまたは作業エリア内のバージョンのどちらのバージョンを使用するかを選択できます。
-
[リモートの変更を適用] をクリックします
変更に新しいデータ タスクが含まれる場合は、ソース接続とターゲット接続を追加する必要があります。
コミットとプッシュ
変更をブランチにコミットしてプッシュできます。作業エリアに適用されていないリモートの変更は上書きされる可能性があるため、コミットしてプッシュする前に [リモートの変更を適用] を実行する必要があります。
-
[プロジェクト] で、プロジェクトの [...] をクリックし、 [コミットしてプッシュ] を選択します。
変更が見つかった場合、 [コミットしてプッシュ] ダイアログが表示されます。
-
コミット メッセージを追加することで、変更された内容を追跡できるようになります。
-
[コミットしてプッシュ] をクリックします
ブランチを削除する
変更をメイン ブランチにマージしたら、ブランチを削除できます。
-
[プロジェクト] で、削除するブランチの [...] をクリックし、 [ブランチを削除] を選択します。
バージョン管理でリモート ブランチを削除することも選択できます。
コミットされていない変更がある場合は、ブランチを削除するとこれらの変更が失われることを確認する必要があります。
プロジェクトのバージョン管理を削除する
プロジェクトをバージョン管理から切断できます。既存のブランチがある場合は、プロジェクトを切断する前に削除する必要があります。
-
[プロジェクト] で、切断するプロジェクトの [...] をクリックし、 [GitHub から切断] を選択します。
他のスペースやテナントとプロジェクトを共有する
プロジェクトのバージョンを、同じテナントまたは別のテナントの別のスペースと共有できます。これは、開発用と本番用など、2 つの環境を作成する場合に便利です。
-
元のプロジェクトと同じ名前で新しいプロジェクトを作成します。
同じユース ケースとプラットフォーム タイプを設定します。さまざまな接続を使用できます。
-
新しいプロジェクトを元のプロジェクトと同じリポジトリとベース ディレクトリ パスに接続します。
情報メモ[コミットしてプッシュ] オプションは選択しないでください。 -
プラットフォーム接続が元のプロジェクトと同じターゲットを指している場合は、データ タスクのデータベースまたはスキーマを必ず変更してください。すべてのタスクのスキーマを変更する 1 つの方法は、リモート変更を適用する前に、 [メタデータ] プロジェクト設定で [すべてのスキーマのプレフィックス] を変更することです。これにより、すべてのタスクがこのプレフィックスで作成されるようになります。
-
すべてのファイルを選択して、リモートの変更を適用します。
-
すべてのランディング タスクに不足しているソース接続を追加します。
ランディング タスクで [ソース データを選択] をクリックし、接続を選択して [保存] をクリックします。
情報メモこの接続は、同じタイプのソースからのもので、元のプロジェクトと同じ名前のテーブルを指す必要があります。 -
すべてのレプリケーション タスクに不足しているソース接続とターゲット接続を追加します。
これにより、別の作業エリアが作成されます。片方の作業エリアでプロジェクトに変更を加え、 [リモートの変更を適用] を使用して他の作業エリアを同期することができます。
セキュリティに関する考慮事項
Qlik Talend Data Integration と GitHub の間で同期されたセキュリティ構成を維持してください。
-
Qlik Talend Data Integration では、権限は複数のプロジェクトが含まれる可能性があるスペースに基づいています。GitHub では、権限はリポジトリに基づいており、リポジトリには複数のプロジェクトが含まれる場合もあります。ベストプラクティスは、それらを調整し、1 つのスペース内のすべてのプロジェクトを同じリポジトリに接続することです。
-
Qlik Talend Data Integration と GitHub では、ユーザーに対して異なる権限とロールが使用されることに注意してください。
ベスト プラクティス
ここでは、バージョン管理を使用してプロジェクトを実施する場合の一般的なベスト プラクティスについて紹介します。
-
GitHub のリポジトリを説明する README ファイルを追加します。詳細については、「README について」を参照してください。
空のリポジトリから始めると、Qlik Talend Cloud バージョン管理によって空の README.md ファイルが自動的に追加されます。
-
一般的には、Qlik Talend Cloud バージョン管理で GitHub リポジトリを管理する必要があります。
-
有効かつ実行テスト済みのプロジェクトのみをコミットします。
データの準備や変換が行われていないランディング タスクまたは登録済みデータ タスクを含むプロジェクトを追加する場合、ソース列はまだ含まれません。ソース列は、タスクが準備され、変換されるときに追加されます。
-
レプリケーション プロジェクトのブランチを作成する場合、ブランチはデフォルトで同じターゲットを使用することに注意してください。つまり、ブランチでタスクを実行すると、メイン バージョンのデータが上書きされる可能性があります。データの損失を回避するには、メイン バージョンと競合しないようにブランチ内のターゲット設定を変更します。
-
ブランチを作成するときに、作業エリアにまだ適用されていないリモートの変更が存在する可能性があります。リモートの変更を破棄しない場合は、ブランチを作成する前または後にリモートの変更を適用します。
-
2 つの異なるブランチで同じデータセットに変更を加えると、解決が難しいマージ競合が発生する可能性があります。
ブランチを使用する
プロジェクトを作成して設計し、準備ができたら、MAIN ブランチを使用して実稼働に展開できます。MAIN のバージョンは実稼働パイプラインに対応しています。最初の展開以降は、MAIN ブランチを直接編集しないでください。
機能の追加やバグの修正など、開発者がプロジェクトに新しい変更を加える場合は、いつでも新しいブランチを作成する必要があります。
開発者は、開発ニーズに合わせていくつでもブランチを作成できます。
-
変更中にデータベースの競合を回避するには、ブランチにスキーマ プレフィックスを使用します。
-
ブランチでは、開発者はいくつでも変更を加えることができ、必要な回数だけコミットおよびプッシュできます。各変更を自己完結型の個別のコミットに分離することをお勧めします。たとえば、データ マートにも影響を与える変換タスクに変更を加える場合は、両方の変更を 1 つのコミットに含めるようにしてください。
-
すべてのチーム メンバーは、特に変更をコミットする前に、いつでも [リモートの変更を適用] を使用して MAIN が最新であることを確認する必要があります。
開発者がブランチでの作業を完了すると、ピア レビュー用のプル リクエストを作成できます。
プル リクエストは、GitHub の [プル リクエスト] で作成します。プル リクエストを作成するブランチを指定する必要があります。
他のチームメンバーによるレビューと承認の後、プルリクエストを MAIN バージョンにマージできます。
最後に、プロジェクトで [リモート変更を適用] を使用して、承認されたブランチの変更を MAIN ブランチ (実稼働) に戻します。
スペースで作業する
大規模で重要な展開の場合は、開発用と本番用の専用スペースを使用して、変更を分離し、パイプラインの整合性を確保することをお勧めします。各スペースのソースとターゲットに専用のデータ接続を使用します。
-
実稼働
MAIN ブランチは、実稼働の内容を反映します。つまり、プロジェクトの MAIN バージョンは 1 つだけであるということです。
実稼働は、PROD などの専用のデータ スペースに分離されます。実稼働スペースには専用の接続が割り当てられます。
実稼働スペース/MAIN ブランチでは直接変更は行われません。すべての変更は、ブランチを使用して、専用の接続を持つ他のスペースで行われます。
GitHub の既存のプロジェクトの MAIN バージョンを再利用できます。GitHub の既存のプロジェクトと同じ名前の空のプロジェクトを作成します。これにより、MAIN ブランチで利用可能な最新バージョンが取得され、編集が開始されます。
ユーザーは新しいブランチを作成し、変更を加え、プル リクエストを作成し、マージして、MAIN/実稼働にプルバックします。
-
開発
開発者は、DEV などの専用データ スペースに変更を分離できます。DEV スペースには専用の接続が割り当てられます。
変更はブランチを使用して分離され、通常は開発者ごとに 1 つのブランチが使用されます。変更中にデータベースの競合を回避するために、ブランチを作成するときにスキーマ プレフィックスを使用します。
-
レビュー/品質検収
レビュー担当者には、開発スペースへのアクセス権と次の接続が付与されます。
-
Qlik Talend Cloud でプロジェクションブランチを開き、テストします。
-
プルリクエストを承認し、GitHub でマージを処理します。
-
承認された変更を MAIN/実稼働にプル バックできる場合は、チームメンバーに通知します。
-
承認された変更を MAIN/実稼働スペースに再度展開する場合、接続を実稼働スペース接続に再割り当てする必要があります。
制限事項
-
ブランチがある場合、バージョン管理を使用してプロジェクトを切断または削除することはできません。プロジェクトを切断または削除する前に、ブランチを削除する必要があります。
-
バージョン管理を使用してプロジェクトの名前を変更することはできません。
-
テナントを削除しても、GitHub のバージョン管理で保存されたオブジェクトは削除されません。これらのオブジェクトは手動で削除する必要があります。
-
リポジトリが多くのプロジェクトで使用されている場合、または Qlik Talend Data Integration に保存されていないファイルが多数含まれている場合は、パフォーマンスが低下する可能性があります。
-
データベース スキーマと接続は、バージョン管理では維持されません。
-
GitHub の Fine-grained personal access token はサポートされていません。
-
2 つのプロジェクトが同じリポジトリ内にある場合でも、ブランチ (メイン ブランチを除く) はリポジトリごとに 1 つのプロジェクトでのみ使用できます。
-
異なるターゲット プラットフォームを使用するプロジェクトからリモート変更を適用することはできません。たとえば、Snowflake のプロジェクトに変更をコミットした場合、その変更を Databricks プロジェクトに適用することはできません。