アクションの作成と管理
アクションの作成、その複数バージョンの保持、およびそれらのバージョンをGitと同期させることは、3つのワークフローではなく1つのワークフローです
目的
アクションの作成、その複数バージョンの保持、およびそれらのバージョンをGitと同期させることは、3つのワークフローではなく1つのワークフローです。このページでは、そのワークフローについて説明します。また、リビルドをトリガーするものと、現在不可能なことについても説明します。
どの種類のアクションを作成するかは、別の質問です。Actionsページで回答されています。
アクションの作成
リポジトリが空の場合、最初に行いたいことはアクションを作成することです。メインページから、画面の右上にある新しいアクションボタンをクリックします。その後、Platform Storeから実行したいアクションの種類を選択するように求められます。
アクションの編集は常にオートセーブモードです。バージョンを使用して、デプロイ済みのプロダクションアクションを変更したくない場合は、そのようにしてください。
高度なモード
Data Processing Engineのアクションはすべて、JSON設定ファイルを介して指定された一連の入力を使用して構成されています。アクションの入力を更新する方法は2つあります。
- グラフィカルユーザーインターフェースを使用する
- JSON設定ファイルを直接編集できる高度なモードを使用する
「高度なモード」を使用すると、少し柔軟性とオプションが増え、高度なユーザーにとって便利になる場合があります。
高度なモードは、カスタムアクションにも非常に便利です。これは、Web上でIDEのような体験を提供するため、コンピュータ上でファイルを管理することなく、プラットフォーム内で直接カスタムPythonスクリプトをコーディングできます。
アクションの管理
プロジェクトが成熟するにつれて、構造と組織化はますます重要になります。これを容易にするために、プラットフォームはアクションをより良く整理して管理するためのいくつかの方法を提供しています：
-
リポジトリ：アクションを異なるセクションに分割し、バージョン管理できるようにします
-
バージョン：プラットフォームは、各アクションのリポジトリごとにオンラインバージョン管理体験を提供します。プラットフォームには独自のバージョン管理システムがありますが、各リポジトリをGitと同期することもできます
-
説明とタグ：各アクションには説明と/またはタグを割り当てることができます。これにより、プロジェクトをドキュメント化できます。特に大規模なチームで協力する際に便利です。
-
系譜：各アクションには、アクションを編集する際にアクセス可能な系譜サブタブが含まれています。これは、アクションを含むすべてのワークフローを表示します。ワークフローを使用すると、複数のアクションの実行をオーケストレーションし、ステージを使用して特定の順序で実行できます。
アクションのリポジトリのバージョン管理
アクションを編集する際は常に自動保存モードになります。既存のアクションを改良しようとする際は、アクションのコードの複数のバージョンを作成することをお勧めします。これにより、作業を実験し、テストするために段階的に変化を導入しながら、常に生産環境にあるバージョンを保持できます。
プラットフォームでは、このバージョン管理はリポジトリレベルで行われます。リポジトリは、アクションツリー表示の上部に表示されるタブです。
個々のアクションをバージョン管理することはできません。むしろ、アクションのリポジトリ全体をバージョン管理できます。バージョン管理パネルは、リポジトリヘッダーの右上部でアクセスできます：
この機能は、Analytics Managerクエリのようなリポジトリを実装する他のコンポーネントでも利用可能です。同じ方法で動作します。クエリ画面で対応するUI要素を探してください。
プラットフォームには2つのバージョン管理システムがあります：
- Data Platformバージョン管理システム：すべてのリポジトリのデフォルトのバージョン管理システム
- Gitバージョン管理：リポジトリをGitと同期することを選択した場合
それでは、実際にどのように動作するか見てみましょう！
プラットフォームのバージョン管理システムを使用する
デフォルトでは、プラットフォーム上の各アクションのリポジトリには、統合されたバージョン管理システムが含まれており、リポジトリに含まれるコード（すなわちアクション）の異なるバージョンを手動で管理できます。
リポジトリには、以下が含まれます：
- デプロイ済みバージョン：ジョブを実行する際に提供されるバージョンです。
- 最新バージョン：エディターパネルを通じて編集中の現在のバージョンです。
リポジトリに1つのバージョンのみがある場合、そのバージョンはデプロイ済みバージョンおよび編集可能なバージョンの両方です。つまり、変更はすぐに生産環境に影響を与えます。
リポジトリに2つ以上のバージョンがある場合、最新バージョンのみを編集できます。その他のバージョン、デプロイ済みバージョンを含むすべてのバージョンは読み取り専用モードになります。
リポジトリの新しいバージョンを作成するには、右上部のバージョン管理パネルを開き、+アイコンをクリックします。
新しいバージョンを作成するために複製するバージョンを選択します。
新しいバージョンを作成した後、デプロイ済みバージョンは変更されません。新しいバージョンを直接編集できます。
再生ボタンをクリックして、新しいバージョンをデプロイ済みバージョンとして設定します。これは、リポジトリのアクションが実行される際に使用されるコードのバージョンです。
Gitにリンクされたリポジトリを使用する
各リポジトリは外部のGitリポジトリにリンクでき、その場合はバージョンがGitコミットと同期されます。これにより、生産環境にデプロイされたバージョンに影響を与えずに、アクションを継続的に更新してテストできます。
リポジトリをGitにリンクする
プラットフォーム上のリポジトリをGitにリンクするには、既存のリポジトリを編集するか、新しいリポジトリを作成するために歯車アイコンをクリックする必要があります。これらのいずれかの操作を実行すると、リポジトリ構成ウィンドウが開きます。
Gitに接続をクリックしてウィンドウを展開します。
ここで最初に入力する必要があるのは、リポジトリのSSH URLです。
これは、一般的に一般的なGitソリューションのリポジトリクローンオプションに見つかります。GitHubの場合、例えば、コード > クローン > SSHで見つけることができます。
次に、FETCHをクリックしてリモートブランチを取得し、使用したいブランチを選択します。
最後に、下部に表示される公開SSHキーをコピーし、Gitソリューション上のアカウントに関連付けられたSSHキーのリストに貼り付けます。GitHubの場合、このチュートリアルに従うことができます。
コミットとプッシュ
リポジトリ内のオブジェクトを変更した後、リポジトリには以下の画像に示すようにコミットされていない変更が表示されます。画像に示された上向きの矢印をクリックして、それらをコミットしてプッシュできます。
プッシュ時に競合がある場合、変更は設定したブランチにプッシュされません。代わりに、現在のブランチの名前と_conflictNのサフィックス（Nは競合の数）を持つ新しいブランチにプッシュされます。例えば、ブランチがcurrent-branchと名付けられ、プッシュ時に競合が発生した場合、新しいブランチはcurrent-branch_conflict1と名付けられます。プッシュ時に再び競合が発生した場合、新しいブランチはcurrent-branch_conflict2と名付けられます。
プルとマージ
画像に示された下向きの矢印をクリックしてリモートの変更をプルします。ポップアップウィンドウが表示され、決定を確認するように求められます。未コミットの変更はすべて失われ、両方のブランチがマージされます。
アクション間でコードを整理して共有する
アクションは、1つの.pyファイル（デフォルトでcustomfunc(event)）で、ドラッグ＆ドロップまたは高度なIDEを通じて追加されます。単一のアクション内にマルチファイルパッケージ構造はありません。
アクション間でコードを再利用するには、ドキュメント化されたパスのいずれかを使用します：
- Python RequirementsフィールドでGitリポジトリを参照します：
- Gitを通じてアクションのリポジトリ全体をバージョン管理します：SSH経由でリンクし、ブランチをフェッチし、Git側で公開SSHキーを貼り付けます。これは、アクション間でコードを共有するための意図されたメカニズムです。
アクション間でグローバルなPython変数は共有されません：各ジョブは、ジョブが終了するとシャットダウンする新しいコンテナで実行されます。再利用可能な値は環境（環境変数）を通じて渡され、複数のアクションとワークフローに同時に割り当てることができます。
アクションからノートブックをトリガーする
カスタムアクションからノートブックをトリガーすることはサポートされていません。ノートブックは、独自の手動スタート/ストップライフサイクルを持つJupyterインスタンスであり、文書化されたフローは逆のものです：ノートブックをアクションに変換することです。
推奨パターン： ノートブックコードをカスタムアクションに変換し、それをワークフローまたはAPIコールを通じてオーケストレーションすることができます。
アクションをプログラムで管理する（CI/CD）
アクションを作成、更新、または削除するための専用のRESTエンドポイントはありません。公式のアプローチはGit同期です：アクションリポジトリをSSH経由でGitリポジトリにリンクし、プラットフォームからコミットしてプッシュするか、プラットフォーム外で行った変更をプルします。
CI/CDの場合、これはアクションを変更するためにリンクされたGitリポジトリへのコミットを意味し、その後プラットフォームからプルします。ワークフローは手動で実行するか、APIコールを通じて実行できます。したがって、アクションのCRUDがGitを通じて行われる場合でも、トリガーは利用可能です。
ビルドの動作
- ビルドをトリガーするもの。 ワーカーのビルドは依存関係の変更によってトリガーされます：依存関係を更新すると環境が再デプロイされます。Git依存関係の場合は、強制ビルドをクリックして再インストールします。
- イメージキャッシュなし。 アクション用の事前構築済みワーカーとイメージキャッシュは、現在利用できません（事前構成済みのノートブックイメージ：Base、Data Science、PySpark、TensorFlowとは異なります）。
- オートセーブとバージョン。 アクションを編集する際は常にオートセーブモードです。生産環境に影響を与えないようにするために、新しいバージョンを作成します：latestが編集可能な状態になり、deployedバージョンは凍結されたままになります。
再ビルドを最小限に抑えるために、共有依存関係を再宣言するのではなく、再利用可能な環境に分割してください。
さらに詳しく
当社のソリューションを実装するためのトレーニングや技術サポートが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして、当社のプロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼する見積もりを取得してください。
Data Platformを構築するチームと直接質問をし、フィードバックを共有し、交流するには、専用のDiscordチャネルにアクセスしてください。
OVHcloudサービスについてサポートが必要な場合は、当社のヘルプセンターでリクエストを作成してください。
当社のユーザーコミュニティに参加してください。