Automation Ops ユーザーガイド

デリバリー:

Automation Cloud Automation Cloud Public Sector Automation Suite

最終更新日時 2024年12月20日

パイプラインを使用したソリューションのデプロイ

UiPath® ソリューション管理を使用すると、オートメーションを必要なすべてのリソースとともにデプロイできます。これをオートメーションの開発ライフサイクルに統合するために、UiPath® Automation Ops™ - パイプラインではソリューションのデプロイのサポートを追加しました。オートメーションのコードを変更するたびに、ソリューションを自動的にテストして再デプロイできるようになりました。

注:

このパイプラインの価値を最大限に引き出すには、UiPath® のコンテキストでのソリューションの概念を理解している必要があります。詳しくは、「ソリューション管理の概要」をご覧ください。

事前構築済みのパイプラインを使用する

Marketplace から事前に構築されたパイプラインを使用できます。 Marketplace パッケージをダウンロードし、そのパッケージからプロセスを作成し、以下の手順で詳しく説明するように、ソリューション固有のロールを割り当てる必要があります。

UiPath® Marketplace からソリューションデプロイパイプラインパッケージをダウンロードします。
Orchestrator のパイプラインランタイムフォルダーにパイプラインプロセスを作成します。 Orchestrator でお使いのパイプラインランタイムフォルダーを確認するには、以下の例に示すように、[ パイプライン ] > [ランタイム設定] に移動します。
パイプラインロボット アカウントに Solution Administrator テナントロールを割り当てます。このロールは、パイプラインがソリューションを管理するすべてのテナントに割り当てる必要があります。

ソリューションのデプロイパイプラインの手順

次の一覧は、ソリューションデプロイパイプラインプロセスに関連する手順の概要を示しています。

リポジトリをクローニングする
ソリューションパイプラインの構成ファイルを 1 行ずつ確認し、そこにあるプロジェクトごとに (各行) 分析、テストの実行、新しいパッケージバージョンのビルド、パブリッシュ、ターゲットプロセス (ソリューションプロジェクトで指定) の更新を行います。
ソリューションプロジェクトを同期して、オートメーションの新しいバージョンが認識されるようにする。
最初の環境でソリューションパッケージをパブリッシュする
ソリューションパッケージ構成ファイルをダウンロードする
ソリューションをデプロイする。
ソリューションをアクティブ化する
承認のために一時停止しています。
ソリューションパッケージを 1 つ目の環境からダウンロードし、2 つ目の環境にアップロードする
ソリューションを 2 つ目の環境にデプロイする
ソリューションをアクティブ化する

パイプラインの引数

次の表に、使用可能なパイプライン引数を示します。

名前	説明
ポリシーを分析する	パイプラインプロセスで使用されるワークフローアナライザーのルールを保持するガバナンスポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
Orchestrator URL	オートメーションパッケージのパブリッシュ先 Orchestrator の URL です。
ソリューションプロジェクト名	ソリューションプロジェクトの名前です。ソリューションプロジェクトの識別に使用されます。
ソリューションパッケージ名	作成されるソリューションパッケージの名前です。
ソリューションパッケージのバージョン	作成されるソリューションパッケージのバージョンです。
AppendBuildNumberToSolutionVersion (ソリューションバージョンにビルド番号を追加)	ソリューションパッケージのバージョンにビルド番号付きのサフィックスを追加できるようにします。これは、後続のパイプライン実行でバージョンの競合を回避するのに役立ちます。既定の引数 (ビルド番号など) の詳細については、「既定のパイプラインプロセス引数」をご覧ください。
ソリューションパッケージの説明	ソリューションパッケージの説明
ソリューションのルートフォルダー	すべてのソリューションコンポーネントがデプロイされるルートフォルダーです。
SolutionPipelineConfigurationFile (任意)	ソリューションパイプライン構成ファイルのリポジトリルートへの相対パス (例: `solution-pipeline-configuration.csv)`。指定しない場合、プロジェクトはリビルドされず、ソリューションパッケージはソリューションプロジェクトの情報のみに基づいて再作成されます。
最初のテナント	ソリューションプロジェクトが定義され、ソリューションが最初にデプロイされるテナント名です。
FirstDeploymentFolder	ソリューションのデプロイ先となる最初のテナント内のフォルダーです。これは、ソリューションのルートフォルダーの親フォルダーになります。空の場合、ソリューションはテナントのルートにデプロイされます。
SolutionFirstDeploymentName (ソリューションの最初のデプロイ名)	後で参照できるように、このインストールの名前。 1 つのソリューションパッケージに複数のデプロイを含めることができます。
DeployToSecondEnvironment	2 つ目の環境へのソリューションのデプロイに関連する残りのパイプラインを有効化します。
SecondTenant (任意)	ソリューションが 2 回目にデプロイされるテナントです。存在しない場合は、 FirstTenant が使用されます。
SecondDeploymentFolder (任意)	ソリューションのデプロイ先となる 2 番目のテナント内のフォルダーです。これは、ソリューションのルートフォルダーの親フォルダーになります。空の場合、ソリューションはテナントのルートにデプロイされます。
SolutionSecondDeploymentName (任意)	後で参照できるように、2 番目のインストールの名前。存在しない場合は、[最初のデプロイ名] が使用されます。
TestingFolder	テストを実行する Orchestrator のフォルダーです。この引数は、 OrchestratorUrl 引数と一緒です。
SkipTesting (テストをスキップ)	テストの実行を無効化/有効化します。既定では、パイプラインはテストを実行します。
承認者のメールアドレス	2 番目の環境へのデプロイを承認するユーザーのメールアドレスです (通常は、最初のデプロイの検証後)。 Action Center で承認タスクを割り当てるために使用されます。
SupportUserEmailAddress (任意)	必要に応じて介入してソリューションのデプロイエラーを修正できるユーザーのメールアドレスです。存在しない場合、ソリューションのデプロイエラーが発生するとパイプラインが中断されます。注: 事前構築済みのパイプラインは汎用的です。特定の各ソリューションに必須のデプロイ設定をカバーするロジックを含めることができませんでした。このため、デプロイが失敗するとパイプラインが中断され、手動修正が求められます。これを回避するには、カスタムパイプラインでソリューションパッケージ構成ファイルを使用します。
SkipSync (任意)	これを使用して、更新なしでソリューションパッケージを再作成できます。
SkipValidation (任意)	プロジェクトの構築手順での検証をスキップします。

デプロイに関する問題の処理

デプロイに失敗した場合は、サポート用のアクションタスクが作成され、パイプラインが中断されるため、修正できます。デプロイが完了したら、パイプラインの実行を再開するためにアクションタスクを完了する必要があります。

デプロイを修正する場合は、タスクを完了する前に、デプロイが [成功] ステータスに達するまで待ってください。

デプロイの問題を手動で修正するには、次の例に示すように、[ デプロイ] > [ ソリューション管理] に移動してデプロイを特定し、[ デプロイ ウィザードを再開] を選択します。

テンプレートからカスタムパイプラインを作成する

ソリューションデプロイパイプラインプロセスは、ほとんどのユースケースをカバーできるように事前に構築されています。ただし、ニーズに合わせてカスタマイズできます。そのためには、Studio からテンプレートを取得して微調整する必要があります。 Studio のテンプレートについて詳しくは、こちらのセクションをご覧ください。

注:

Studio の > テンプレートで [プレリリースを含める] オプションが有効化されていることを確認します。

カスタムパイプラインを作成するには、次の手順に従います。

ソリューション管理でソリューションプロジェクトを作成します。
オートメーションプロジェクトを GitHub または Azure リポジトリのソース管理下に置きます。ソリューションのすべてのプロジェクトコードは、同じ Git リポジトリに保存する必要があります。
新しい構成ファイル (詳しくは、「ソリューションパイプラインの設定ファイル」を参照) をリポジトリに追加します。このファイルでは、手順 1 でソリューションプロジェクトで使用したオートメーションと、リポジトリ内のそれぞれのプロジェクトパスとのマッピングが保持されます。次の例は、ソリューションパイプラインの構成ファイルを示しています。
パイプラインロボット アカウントに Solution Administrator テナントロールを割り当てます。このロールは、パイプラインがソリューションを管理するすべてのテナントに割り当てる必要があります。 パイプラインロボット アカウントは、パイプラインの実行に使用するロボットアカウントであり、Orchestrator の [パイプライン] フォルダーに割り当てられます。

パイプラインのロボットアカウントロールについて詳しくは、「初期設定」をご覧ください。

Orchestrator の [パイプライン] フォルダーは、[パイプライン] の [ランタイム設定] で確認できます。
Automation Ops でパイプラインを作成します。リポジトリ全体で変更 (ソリューションのプロジェクトのいずれかの変更) が発生するたびにパイプラインをトリガーするには、パイプライン定義の最初の手順でプロジェクトだけでなく、リポジトリのみを選択します。
パイプラインの引数を設定し、パイプラインを開始します。

ソリューションパイプラインの構成ファイル

ソリューションパイプライン構成ファイルは、ソリューションで使用されるオートメーションをソースコードプロジェクトにマッピングします。パイプラインでは、構築するプロジェクトと、ソリューションを更新するためにそれらを配置すべき場所を把握するために、このようなマッピングが必要です。この形式は、事前構築済みのパイプラインで使用される提案にすぎません。カスタムパイプラインプロセスを作成するときに、独自の形式を使用できます。

ソリューションパイプラインの設定は、次の形式の .csv ファイルです。

PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTestsPathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests

重要:

1 行目は .csv ファイルのヘッダーで、必須です。

各行は、プロジェクトで実行されるアクションを設定します。

名前	説明
PathToProjectJson	リポジトリのルートからproject.jsonする相対パスです。
PackageName	プロジェクトから作成されたパッケージの名前です。
Orchestrator のフォルダー	Orchestrator でプロセスを更新する場所です。
プロセス名	更新するプロセスの名前です。
テストを実行	テストをパイプラインの一部として実行するかどうか。

次に、構成ファイルの例を示します。

PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
Blank Process 16/project.json,Blank.Process.16,Finance,Blank.Process.16,True
ComputeSLA/project.json,ComputeSLA,Finance,ComputeSLA,FalsePathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
Blank Process 16/project.json,Blank.Process.16,Finance,Blank.Process.16,True
ComputeSLA/project.json,ComputeSLA,Finance,ComputeSLA,False