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

このガイドでは、DevOps、Marketplace、スペースを使用してリリース管理プロセスを設定する手順を説明します。開発環境ですでにワークフローを構築していることを前提に、追加の環境を設定し、既存のワークフローをこれらの新しい環境にデプロイする手順を案内します。

以下で説明する DevOps と Marketplace の使用は、リリース管理プロセスを実装する方法の 1 つです。Palantir プラットフォームでは、Global Branching の使用など、他の方法でも実装できます。

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

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

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

1 個のスペース内に複数のワークフローを配置でき、それらの間でリソースを共有できます。

エンロールメントでスペースを作成する機能が無効になっている場合は、新しいスペースの作成について Palantir サポートにお問い合わせください。

環境は DevOps アプリケーションから管理でき、エンロールメント全体で設定され、すべてのストアに影響します。テーブルの設定オプションに移動し、続いて環境の設定を選択すると、環境設定を構成できます。

環境設定から、ユーザーは推奨される環境や、該当するストアのインストールを含むスペースを追加したり、別のスペースを選択したりできます。また、環境のリストを並べ替えて、このページでの表示順を決定することもできます。ユーザーは、所有者アクセス権を持つスペースの環境のみ編集、追加、削除できます。また、スペースは 1 個のエンロールメントにのみ関連付けられている必要があります。

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

DevOps を使用して、開発環境のリソースを製品にパッケージ化します。ワークフローは 1 件以上の製品にパッケージ化できます。一般的な分割方法は次のとおりです。

• データ接続リソースを含むデータソース製品。
• オブジェクトタイプとその元データセット、および汎用的なアクションと関数を含むオントロジー製品。
• Workshop モジュール、およびワークフロー固有のアクションと関数を含む 1 件以上のユースケース製品。
  
  
  
  製品の作成方法に関するガイドを参照してください。
  
  

一般的には、プロジェクトと製品の間で 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 のアプリケーションで使用されている場合は、アクションタイプをそのユースケースとともにパッケージ化します。
  • アクションタイプには関数を利用できます。この場合、アクションタイプは、その処理を担う関数への依存関係を持ちます。アクションタイプは、その処理を担う関数と同じ製品にパッケージ化します。
  • アクションタイプが、別々の製品にパッケージ化された複数のユースケースで使用される場合があります。この場合、アクションタイプや、必要に応じてその処理を担う関数などの共通機能を切り出し、専用の製品またはコアオントロジー製品にまとめることができます。

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

複数のプロジェクトのパッケージ化に関する指針

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

関連するプロジェクトを製品にパッケージ化します。ある製品の内容が下流の製品の入力を満たせるように、製品を組み合わせられる構成にする必要があります。

リンクされた製品について詳しくはこちら。

3. 製品のリリースを管理する

プロジェクトを製品にパッケージ化したら、それらの製品を 2 番目の環境にインストールできます。Development、Test、Production の環境を使用するリリース管理プロセスでは、これは Test 環境にあたります。Marketplace を通じた製品のインストールについて詳しくはこちら。

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

DevOps アプリケーションの「環境」タブで環境を表示できます。ユーザーは、設定済みの環境で製品のインストールを表示できます。ストア内でパッケージ化された製品は左側の列に表示され、development、test、production 環境など、ユーザーが設定した環境でこれらの製品をインストールおよびアップグレードできます。

ユーザーは、環境内のインストールの全体像と、各環境の概要情報を確認できます。ここからインストールに直接移動し、インストール、アップグレード、リリースチャネルの編集、インストールのロックなどの操作を実行できます。

個々の環境を選択すると、その環境の詳細を表示できます。

複数の製品のインストールに関する指針

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

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

DevOps で環境を表示する

DevOps アプリケーションの環境タブで環境を表示できます。各ストアの開発環境には、そのストアのソース製品が含まれており、ユーザーはこれらを他の環境にインストールできます。ユーザーは、設定済みの環境でこれらの製品のインストールを表示できます。ストア内でパッケージ化された製品は development 環境を表し、その後、development、test、production 環境など、ユーザーが設定した環境でこれらの製品がインストールおよびアップグレードされます。