DevOps を使用したリリース管理

このガイドでは、DevOps、Marketplace、およびスペースを使用してリリース管理プロセスを設定する手順を説明します。開発環境でワークフローをすでに確立していると仮定し、以下の手順は、追加の環境を設定し、既存のワークフローをこれらの新しい環境にデプロイするプロセスを案内することを目的としています。

1. スペースを使用して環境を設定する

Palantir プラットフォームの スペース を環境として使用します。必要な環境ごとに 1 つのスペースを作成します。たとえば、Development、Test、Production スペースを作成できます。Palantir プラットフォーム内のすべてのリソースとプロジェクトはスペース内に存在するため、現在ユーザーのリソースがあるスペースを Development スペースとして使用できます。その現在のスペースを Development スペースとして使用する場合は、追加の Test および Production スペースを作成するだけです。

スペースの作成と設定方法については、スペースに関するドキュメント を参照してください。

スペース内に複数のワークフローが存在し、リソースを共有できます。

エンロールメントでスペースの作成が無効になっている場合は、Palantir サポートに連絡して新しいスペースを作成してください。

2. リソースを製品にパッケージ化する

開発環境からリソースを製品にパッケージ化するには DevOps を使用します。ワークフローを 1 つまたは複数の製品にパッケージ化できます。一般的な分割は次のようになります。

• データ接続リソースを含むデータソース製品。
• オブジェクトタイプとその元データセット、一般的なアクションと関数を含むオントロジー製品。
• Workshop モジュール、およびワークフロー固有のアクションと関数を含む 1 つまたは複数のユースケース製品。

製品の作成方法に関するガイドを確認してください。

一般に、プロジェクト全体を製品としてパッケージ化することがベストプラクティスです。これにより、プロジェクトと製品の間に 1:1 の関係が維持され、リソースに適切な製品を特定するプロセスが簡素化されます。

オントロジーエンティティはどのプロジェクトにも属していません。オブジェクトタイプ、リンクタイプ、アクションタイプ、および関数をパッケージ化する場所を決定する際は、次のガイダンスを考慮してください。

• オブジェクトタイプは、元 データセット がパッケージ化されている製品にパッケージ化する必要があります。

• リンクタイプに使用される 2 つのオブジェクトタイプのうち、リンクタイプは最も 下流 のオブジェクトタイプと同じ製品にパッケージ化する必要があります。たとえば、Logistics Use Case というユースケース製品に Truck というオブジェクトタイプがあり、Core Ontology 製品の Plant オブジェクトタイプにリンクがある場合、リンクタイプは Logistics Use Case 製品にパッケージ化する必要があります。この状況では、Logistics Use Case 製品が Core Ontology 製品の 下流 に位置し、Core Ontology 製品が Use Case X 製品の上流に位置します。両方のオブジェクトタイプが同じ製品にある場合、その製品にリンクタイプをパッケージ化してください。
  
  
  
  

• アクションタイプについては、次の点を考慮してください。

  • アクションタイプは通常、暗黙的にユースケースに関連付けられています。この場合、関連するユースケース製品にアクションタイプをパッケージ化する必要があります。たとえば、Reroute Truck アクションタイプが Logistics Use Case のアプリケーションで使用されている場合、そのユースケースにアクションタイプをパッケージ化します。
  • アクションタイプは関数を利用していることがあります。この場合、アクションタイプはそれを利用した関数に依存します。アクションタイプを関数と同じ製品にパッケージ化します。
  • アクションタイプは、異なる製品にパッケージ化された複数のユースケースで使用されることがあります。この場合、アクションタイプやそれを利用した関数などの共通機能を独自の製品またはコアオントロジー製品に分離できます。

• 関数は、関数コードリポジトリやロジックリソースなど、それを生成するソースと同じ製品にパッケージ化する必要があります。

複数のプロジェクトをパッケージ化するためのガイダンス

ワークフローはしばしば複数のプロジェクトにまたがるリソースに依存しており、プロジェクトが製品にパッケージ化される場合も同様です。製品は一緒に構成され、1 つの製品にパッケージ化されたリソースが下流の製品の入力として使用できます。これにより、複数のプロジェクトにまたがる大規模なワークフローのリリース管理が可能になります。たとえば、データソース製品、コアオントロジー製品、および複数のユースケース製品をパッケージ化できます。ユースケース製品には、コアオントロジー製品の一部となるオブジェクトタイプに依存する Workshop アプリケーションや他のリソースが含まれる可能性があります。この状況では、ユースケース製品はそれらのオブジェクトタイプを入力として必要とし、それらの入力はコアオントロジー製品によって満たされます。

関連するプロジェクトを製品にパッケージ化します。製品は一緒に構成される必要があり、1 つの製品の内容が下流の製品の入力を満たすことができるようにします。

リンクされた製品についてさらに学びましょう。

3. 製品のリリース管理

プロジェクトが製品にパッケージ化されたら、これらの製品を第 2 の環境にインストールできます。Development、Test、および Production 環境を持つリリース管理プロセスでは、これが Test 環境になります。Marketplace を通じて製品をインストールする方法についてさらに学びましょう。

その後のすべての環境について、このプロセスを繰り返します。環境に製品をインストールした後、インストール設定 をカスタマイズすることでアップグレードを自動化できます。リリースチャネルやメンテナンスウィンドウなどの追加のカスタマイズも、初回インストール時に設定できます。

複数の製品をインストールするためのガイダンス

複数の製品を同時にインストールする場合は、これを行う際の製品の順序を考慮してください。上流の製品は、その下流の依存関係よりも先にインストールする必要があります。下流の製品をインストールする場合、その入力は通常、同じ環境内のリソースによって満たされる必要があります。たとえば、Test 環境のリソースを Test 環境のインストールの入力として使用し、他の環境も同様にします。

リンクされた製品機能は、パッケージ化時にどの製品が互いの入力を満たすかを示します。