- リリース ノート
- はじめに
- ガバナンス
- ソース管理
- CI/CD パイプライン
- フィードの管理
- ログ
パイプラインを使用したソリューションのデプロイ
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,RunTests
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
.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,False
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
Blank Process 16/project.json,Blank.Process.16,Finance,Blank.Process.16,True
ComputeSLA/project.json,ComputeSLA,Finance,ComputeSLA,False
ソリューション パッケージ構成ファイルは、ソリューションの自動デプロイの設定を制御するために使用されるファイルです。
ソリューション パイプラインの構成ファイルは、ソリューション パッケージの構成ファイルとは異なります。 ソリューション パイプラインの設定では、ソリューションとプロジェクト間のマッピングが保持されます。 ソリューション パッケージの構成には、デプロイ用のソリューション コンポーネントの構成が格納されます。
一般的なユース ケースは、ソリューションで使用される資格情報アセットにパスワードを設定する場合です。
ソリューションに含まれる資格情報アセットのパスワードはソリューション パッケージに保存されないため、デプロイ時に指定する必要があります。
パイプラインの一部としてパスワードを設定するには、ソリューション パッケージの構成ファイルをダウンロードし、それに応じて更新する必要があります。