メイン コンテンツをスキップする 補完的コンテンツへスキップ

バージョン管理によるプロジェクトの管理

バージョン管理を使用して、データプロジェクトの開発を管理し、変更点を追跡できます。

情報メモQlik Talend Cloud スターター のサブスクリプションでは、バージョン管理は利用できません。

バージョン管理を使用する場合、設計中にプロジェクトのバージョンをコミットできます。これにより、変更を元に戻すことや、プロジェクトの 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 を構成できます。はじめに に従って準備したことを確認してください。

  1. をクリックし、 [GitHub 構成] クリックします。

  2. 組織および はじめに で説明されている GitHub personal access token を使用して認証を設定します。

  3. OKをクリックします。

情報メモ個人スペースに GitHub - バージョン管理タイプの接続が作成されます。すべてのユーザーには個人バージョンの管理接続があるため、管理する必要はありません。

プロジェクトをリポジトリに接続できるようになりました。

プロジェクトをリポジトリに接続する

バージョン管理の使用を開始する前に、プロジェクトをリポジトリに接続する必要があります。GitHub への接続が設定されていることを確認してください。

プロジェクトをバージョン管理に接続します。

テナント設定時の地域のドロップダウン リスト。
  1. [プロジェクト] で、プロジェクトの [...] をクリックし、 [バージョン管理に接続] を選択します。

  2. プロジェクトを関連付けるリポジトリを選択します。

  3. ベース ディレクトリ パスを追加します。

    GitHub の既存のプロジェクトに接続する場合は、同じパスを使用する必要があります。

  4. 接続後にプロジェクトをコミットし、リモート リポジトリにプッシュすることを選択できます。コミット メッセージを入力します。

    コミットしてプッシュしない場合、作業エリアにメイン ブランチが作成されますが、リモート リポジトリには作成されません。

  5. [接続] をクリックします。

プロジェクトは選択したリポジトリに接続されました。これは、プロジェクト カードの下部に 、リポジトリの名前、現在のブランチとともに示されます。

プロジェクトを開くと、タイトル行にバージョン管理オプションを含む GitHub メニューが表示されます。プロジェクト名には現在のブランチの名前も追加されます。

バージョン管理によるプロジェクトの開発

バージョン管理は、次のようなさまざまな方法で使用できます。

  • メイン ブランチでの直接作業。これは主に、プロジェクトで変更を追跡する 1 人の開発者に適していますが、同期して作業する開発者のグループでも使用できます。

  • 複数の開発者が貢献できるブランチ戦略での作業。ブランチを作成して、新しい機能や変更を互いに分離することもできます。

単一開発者プロジェクト向けの簡素化されたワークフロー

プロジェクトのメイン ブランチで直接作業できます。このアプローチはよりシンプルで操作も少なくなりますが、変更を追跡することはできます。開発者が複数いる場合は、同期をとるように注意する必要があります。

適用するプロジェクトに変更を加えたら、 [コミットしてプッシュ] を実行します。

複数の開発者によるプロジェクトのワークフロー

このワークフローは、プロジェクトに複数の開発者が関わっている場合、または変更を分離する場合に使用できます。これには、他のユーザーと共有できる開発ブランチの作成が含まれます。このワークフローにより、開発者は互いの変更を追跡し、変更をメイン ブランチにマージするタイミングを決定できます。

バージョン管理を使用した複数の開発者によるプロジェクトのワークフロー

  1. メイン ブランチから新しい開発ブランチを作成します。ブランチをより多くのユーザーと共有できます。

  2. プロジェクトで必要な変更をすべて実行します。

    情報メモデータベース スキーマと接続は、バージョン管理では維持されません。
  3. 他のブランチからのリモート変更を自分の作業エリアに適用し、他のブランチからの変更に対応できるようにします。これは、競合する変更を回避または軽減するのに役立ちます。

    競合する可能性のある変更を含む 2 つのブランチがある場合、回避策は次のとおりです。

    1. 両方の作業エリアに変更をコミットします。

    2. 両方のブランチをメインにマージします。

    3. リモートの変更を再度適用します。

  4. 変更を開発ブランチにコミットしてプッシュします。すべてのオブジェクトがプッシュされるため、コミットする前にプロジェクトを検証することをお勧めします。

  5. 開発の準備ができたら、作業エリアからメイン ブランチに変更をマージします。開発ブランチをメイン ブランチにマージするには、GitHub でプルリクエストを開いて実行する必要があります。メイン ブランチにマージするブランチの承認を設定できます。詳細については、「GitHub プルリクエストのドキュメント」を参照してください。

新しいブランチを作成

  1. [プロジェクト] で、プロジェクトの [...] をクリックし、 [新しいブランチを作成] を選択します。

    プロジェクトはバージョン管理に接続されている必要があります。

  2. メイン ブランチからブランチを作成する場合に選択します。

  3. ブランチの名前を入力します。

  4. [すべてのスキーマのブランチ プレフィックス] で、プロジェクト内のすべてのスキーマに追加するプレフィックスを設定します。こうすることで、すべてのスキーマに一意の名前を付けることができ、名前の競合を回避できます。

  5. [作成] をクリックします

メインから新しいブランチが作成され、リポジトリからチェックアウトされます。ブランチにはプロジェクトの新しいバージョンが含まれており、すべてのタスクのステータスは 「新規」になります。つまり、準備されておらず、データが含まれていません。

リモート変更の適用

リモート リポジトリからの変更を作業エリアに適用できます。これは、たとえば GitHub や他のツールなど、Qlik Cloud 統合バージョン管理の外部で作成された変更である可能性があります。これにより、変更をブランチにコミットしてプッシュするときに競合を回避できます。

  1. [プロジェクト] で、プロジェクトの [...] をクリックし、 [リモートの変更を適用] を選択します。

    変更が見つかった場合は、 [作業エリアにリモートの変更を適用] ダイアログが表示されます。

  2. 変更を適用するタスクを選択し、変更を検査できるようになりました。変更ごとに、リモート バージョンまたは作業エリア内のバージョンのどちらのバージョンを使用するかを選択できます。

  3. [リモートの変更を適用] をクリックします

変更に新しいデータ タスクが含まれる場合は、ソース接続とターゲット接続を追加する必要があります。

情報メモ選択したタスクのみを適用する場合は、プロジェクトの構造的妥当性を維持するように注意する必要があります。たとえば、新しいストレージ タスクを適用する場合は、ソースのランディング タスクも適用する必要があります。ランディング データセットを手動で追加することはできません。

コミットとプッシュ

変更をブランチにコミットしてプッシュできます。作業エリアに適用されていないリモートの変更は上書きされる可能性があるため、コミットしてプッシュする前に [リモートの変更を適用] を実行する必要があります。

  1. [プロジェクト] で、プロジェクトの [...] をクリックし、 [コミットしてプッシュ] を選択します。

    変更が見つかった場合、 [コミットしてプッシュ] ダイアログが表示されます。

  2. コミット メッセージを追加することで、変更された内容を追跡できるようになります。

  3. [コミットしてプッシュ] をクリックします

ブランチを削除する

変更をメイン ブランチにマージしたら、ブランチを削除できます。

  1. [プロジェクト] で、削除するブランチの [...] をクリックし、 [ブランチを削除] を選択します。

    バージョン管理でリモート ブランチを削除することも選択できます。

    コミットされていない変更がある場合は、ブランチを削除するとこれらの変更が失われることを確認する必要があります。

プロジェクトのバージョン管理を削除する

プロジェクトをバージョン管理から切断できます。既存のブランチがある場合は、プロジェクトを切断する前に削除する必要があります。

  1. [プロジェクト] で、切断するプロジェクトの [...] をクリックし、 [GitHub から切断] を選択します。

他のスペースやテナントとプロジェクトを共有する

プロジェクトのバージョンを、同じテナントまたは別のテナントの別のスペースと共有できます。これは、開発用と本番用など、2 つの環境を作成する場合に便利です。

  1. 元のプロジェクトと同じ名前で新しいプロジェクトを作成します。

    同じユース ケースとプラットフォーム タイプを設定します。さまざまな接続を使用できます。

  2. 新しいプロジェクトを元のプロジェクトと同じリポジトリとベース ディレクトリ パスに接続します。

    情報メモ[コミットしてプッシュ] オプションは選択しないでください。
  3. プラットフォーム接続が元のプロジェクトと同じターゲットを指している場合は、データ タスクのデータベースまたはスキーマを必ず変更してください。すべてのタスクのスキーマを変更する 1 つの方法は、リモート変更を適用する前に、 [メタデータ] プロジェクト設定で [すべてのスキーマのプレフィックス] を変更することです。これにより、すべてのタスクがこのプレフィックスで作成されるようになります。

  4. すべてのファイルを選択して、リモートの変更を適用します。

  5. すべてのランディング タスクに不足しているソース接続を追加します。

    ランディング タスクで [ソース データを選択] をクリックし、接続を選択して [保存] をクリックします。

    情報メモこの接続は、同じタイプのソースからのもので、元のプロジェクトと同じ名前のテーブルを指す必要があります。
  6. すべてのレプリケーション タスクに不足しているソース接続とターゲット接続を追加します。

これにより、別の作業エリアが作成されます。片方の作業エリアでプロジェクトに変更を加え、 [リモートの変更を適用] を使用して他の作業エリアを同期することができます。

セキュリティに関する考慮事項

Qlik Talend Data Integration と GitHub の間で同期されたセキュリティ構成を維持してください。

  • Qlik Talend Data Integration では、権限は複数のプロジェクトが含まれる可能性があるスペースに基づいています。GitHub では、権限はリポジトリに基づいており、リポジトリには複数のプロジェクトが含まれる場合もあります。ベストプラクティスは、それらを調整し、1 つのスペース内のすべてのプロジェクトを同じリポジトリに接続することです。

  • Qlik Talend Data Integration と GitHub では、ユーザーに対して異なる権限とロールが使用されることに注意してください。

ベスト プラクティス

ここでは、バージョン管理を使用してプロジェクトを実施する際のベスト プラクティスについて紹介します。

  • GitHub のリポジトリを説明する README ファイルを追加します。詳細については、「README について」を参照してください。

  • 有効かつ実行テスト済みのプロジェクトのみをコミットします。

    データの準備や変換が行われていないランディング タスクまたは登録済みデータ タスクを含むプロジェクトを追加する場合、ソース列はまだ含まれません。ソース列は、タスクが準備され、変換されるときに追加されます。

  • レプリケーション プロジェクトのブランチを作成する場合、ブランチはデフォルトで同じターゲットを使用することに注意してください。つまり、ブランチでタスクを実行すると、メイン バージョンのデータが上書きされる可能性があります。データの損失を回避するには、メイン バージョンと競合しないようにブランチ内のターゲット設定を変更します。

  • ブランチを作成するときに、作業エリアにまだ適用されていないリモートの変更が存在する可能性があります。リモートの変更を破棄しない場合は、ブランチを作成する前または後にリモートの変更を適用します。

制限事項

  • ブランチがある場合、バージョン管理を使用してプロジェクトを切断または削除することはできません。プロジェクトを切断または削除する前に、ブランチを削除する必要があります。

  • バージョン管理を使用してプロジェクトの名前を変更することはできません。

  • テナントを削除しても、GitHub のバージョン管理で保存されたオブジェクトは削除されません。これらのオブジェクトは手動で削除する必要があります。

  • リポジトリが多くのプロジェクトで使用されている場合、または Qlik Talend Data Integration に保存されていないファイルが多数含まれている場合は、パフォーマンスが低下する可能性があります。

  • データベース スキーマと接続は、バージョン管理では維持されません。

  • GitHub の Fine-grained personal access token はサポートされていません。

  • 2 つのプロジェクトが同じリポジトリ内にある場合でも、ブランチ (メイン ブランチを除く) はリポジトリごとに 1 つのプロジェクトでのみ使用できます。

  • 異なるターゲット プラットフォームを使用するプロジェクトからリモート変更を適用することはできません。たとえば、Snowflake のプロジェクトに変更をコミットした場合、その変更を Databricks プロジェクトに適用することはできません。

このページは役に立ちましたか?

このページまたはコンテンツに、タイポ、ステップの省略、技術的エラーなどの問題が見つかった場合は、お知らせください。改善に役立たせていただきます。