- リリース ノート
- はじめに
- ガバナンス
- ソース管理
- CI/CD パイプライン
- フィードの管理
- ログ
UiPath® Automation Ops™ - パイプライン
Automation Ops™ - パイプライン を使用すると、継続的インテグレーション/継続的デリバリー システムを簡単に設定して、Github や Azure DevOps などの外部リポジトリでオートメーション プロジェクトのコードを管理できます。
パイプラインには、実際の環境でコードの変更に使用されるオートメーション プロセスに応じた一連のステップが含まれています。 これらのプロセス ( パイプライン プロセスとも呼ばれます) では、 パイプライン アクティビティ パッケージを使用します。 ユーザーがこれらのパイプライン プロセスを表示するには、そのパイプライン プロセスを含む Orchestrator フォルダーへのアクセス権を持っている必要があります。
パイプラインがトリガーされると、Unattended ロボットを使用して関連するパイプライン プロセスを実行するジョブが開始されます。
- Robot のバージョン:
- 2021.10 および 2022.4:
.NET Desktop Runtime 6.0.*は、ロボット端末に手動でインストールする必要があります。 - 2022.8 以降:
.NET Desktop Runtimeはロボットとともに自動的にインストールされます。
- 2021.10 および 2022.4:
- プロセスの詳細:
Orchestrator の基本構成には、パイプライン プロセスとロボット アカウントを含む専用フォルダーと、パイプライン ジョブを実行するためのマシンまたはマシン テンプレートが含まれます。
クイック セットアップ中に作成されたロボット アカウントは必須です。 すべてのパイプライン (Orchestrator のジョブ) が代わりに実行されます。 ロボット アカウントを削除すると、パイプライン ランタイムの設定が無効になり、クイック セットアップを再実行する必要があります。
Orchestrator 内の専用パイプライン フォルダーを削除すると、そのフォルダーに関連付けられているすべてのパイプラインが中断されます。
Automation Ops™ - パイプラインを初めて設定する際に、クイック セットアップ ウィンドウが表示され、今後のパイプラインを実行するテナントとマシンの種類を選択できます。 実際の環境の既存マシンを使用するか、「PipelinesRobot」という名前の新しいサーバーレス マシンを自動的に作成することができます。
新しいサーバーレス マシンを作成する場合は、テナントで十分なロボット ユニットが利用可能であることを確認してください。
クイック セットアップでは、「パイプライン」という名前の新しいフォルダーと以下のロールが自動的に作成されます。
- パイプラインのテナント ロール
- パイプラインのフォルダー ロール
パイプライン ロボットには、以下のロールが自動的に割り当てられます。
- テナント: PipelinesTenantRole、Allow to be Automation User、Allow to be Automation Publisher
- Pipelines フォルダー: PipelinesFolderRole、Automation User、Automation Publisher
パイプライン用に作成したロボット アカウントが、対象の Orchestrator フォルダーにも割り当てられていることを確認してください。この割り当ては、パイプラインはそのアカウントで動作するために必要です。詳細については「アカウントのアクセス権を設定する」をご覧ください。
[テストを実行] アクティビティは、指定した Orchestrator フォルダー内のテストを実行します。 Pipelines ロボット アカウントはそれぞれのフォルダーにパッケージをパブリッシュしますが、テストは Pipelines ロボット アカウントだけでなく、テスト実行の対象とするそのフォルダー内の任意のロボット アカウントで実行できます。
また、既定で、以下の定義済みパイプライン プロセスを利用できます。
|
Build.and.publish |
複製 -> 分析 -> 構築 -> パブリッシュ |
|
Copy.package.between.environments |
パッケージをダウンロード -> パッケージをパブリッシュ |
|
Update.process.from.code |
複製 -> 分析 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 |
|
Update.with.tests |
複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 |
|
Build.and.promote.with.approval |
複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新 |
- SkipTesting - パイプライン中にテスト ケースを実行するかどうかを選択できます。
- TestingFolder - テストが実行される Orchestrator のフォルダーです。
- AnalyzePolicy - パイプライン プロセスで使用されるワークフロー アナライザーのルールを保持するガバナンス ポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
- SkipValidation - パッケージの構築前の検証をスキップできます。この値は既定では無効化されています。
- Approver - Action Center で作成されたタスクの承認者のメール アドレスです。
- FirstOrchestratorUrl - 構築されたパッケージのパブリッシュ先 Orchestrator の URL です。
- FirstOrchestratorFolder - 構築されたパッケージのパブリッシュ先 Orchestrator のフォルダーです。
- SecondOrchestratorUrl - 構築されたパッケージの承認後のパブリッシュ先 Orchestrator の URL です。
- SecondOrchestratorFolder - 構築されたパッケージの承認後のパブリッシュ先 Orchestrator のフォルダーです。
- HaveSamePackageFeed - このフィールドは、既定で「False」に設定されます。1 つ目の環境と 2 つ目の環境で同じパッケージ/ライブラリ フィードを使用している場合は、これを「True」に設定します。
- ProcessName - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
初期設定で作成した Cloud サーバーレス ロボットのサイズは 標準 です。 [テストを実行] アクティビティを使用するときに、Cloud サーバーレス ロボットが格納されている Orchestrator フォルダーが含まれる場合は、ロボットのサイズが標準であることを確認してください。
[Build] アクティビティを使用するときは、構築しているオートメーション プロジェクトとプロセスを実行しているマシンとの相互運用性の要件を検証してください。
Windows ベースのマシンを使用する必要があります。
.settings、 .project、 .tmhなどの関連するプロジェクト フォルダーすべてをコミットする必要があります。
Orchestrator の設定が完了したら、Automation Ops™ -パイプライン、コードを保持する GitHub リポジトリ、および Orchestrator パイプラインのランタイム環境との初期連携を設定する必要があります。 その際、最初のパイプラインも作成します。
次の手順を実行します。
- Automation Cloud™ で、左側のナビゲーション バーから [Automation Ops™ > パイプライン ] に移動します。
- [新しいパイプライン] を選択します。外部リポジトリがソース管理に接続されている場合は、そこにも自動的に接続されます。
手記： 1 つの GitHub 組織に同時に接続できる UiPath® Automation Cloud™ の組織は 1 つだけです。
- [場所] タブで、外部リポジトリの組織、リポジトリ、ブランチ、およびオートメーション プロジェクト (任意) を選択します。[次へ] をクリックします。
- [パイプラインの定義] タブで、以下の手順を実行します。
- パイプライン プロセスを選択します。パイプライン プロセスに引数が用意されている場合は、その値を追加できます。
- [保存して実行] タブで、以下を設定します。
- プロジェクト名 - パイプライン プロジェクトの名前を入力します。既定では、この名前はリポジトリの名前とパイプライン オートメーション プロジェクトの名前で構成されます。
- 説明 - 必要に応じて、説明を追加します。
- パイプラインの実行方法 - パイプラインの実行方法を以下から選択します。
- コミットのたびに実行 - パイプライン オートメーションは、選択したプロジェクトのリポジトリのコードが変更されるたびにトリガーされます。
- 手動で実行 - パイプライン オートメーションは手動でトリガーされます。
注:手動でトリガーされるパイプラインでは、ジョブの開始時に使用されるコミットは、選択した
project.jsonファイルのフォルダーでの最新のコミットです。そのコミットでフォルダー内のファイルが変更されていない場合、リポジトリ全体の最新のコミットではありません。
- [保存] をクリックしてパイプラインを保存するか、[保存して実行] をクリックしてパイプラインを保存し、実行します。
手順 1 でリポジトリから特定のプロセスが選択されておらず (オートメーション プロジェクトが選択されていない)、パイプラインがコミットによってトリガーされるよう設定されている場合、パイプラインはリポジトリ内の任意のコミットによってトリガーされます。
ProjectPath 引数には、パイプラインの設定の手順 [場所] の [オートメーション プロジェクト (任意)] フィールドで選択した値が入力されます。
ProjectPath 引数は空のままになります。このシナリオは、オートメーション プロジェクトが 1 つのみであるリポジトリに使用できます。
パイプラインを手動で実行する
- Automation Cloud™ で、左側のナビゲーション バーから [Automation Ops™ ] に移動します。
- [パイプライン] を選択します。利用可能なパイプラインが表示されます。
- パイプラインを選択して [新しいジョブを開始] を選択します。これによりパイプラインの実行がトリガーされ、各ステップの進行状況をリアルタイムで確認できます。
ここから [ パイプライン設定] を選択して、パイプラインを編集することもできます。 これにより、パイプラインの概要が表示され、そこから以下の操作を実行できます。
-
パイプラインを編集 - パイプラインを更新する場合に選択します。 更新できるのは、パイプライン名、説明、トリガーの種類、カスタム パイプライン引数のみです。 場所とパイプライン定義は変更できません。
-
パイプラインを削除 - パイプラインを削除する場合に選択します (パイプラインに関連するすべての情報が削除されます)。
既定で、以下の定義済みパイプライン プロセスを利用できます。
|
Build.and.publish |
複製 -> 分析 -> 構築 -> パブリッシュ |
|
Copy.package.between.environments |
パッケージをダウンロード -> パッケージをパブリッシュ |
|
Update.process.from.code |
複製 -> 分析 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 |
|
Update.with.tests |
複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 |
|
Build.and.promote.with.approval |
複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新 |
これらの既定のパイプライン プロセスでは、次の一連の引数を利用できます。
- Build.and.promote.with.approval プロセス:
- ProcessName - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
- Approver - Action Center で作成されたタスクの承認者のメール アドレスです。
- SkipTesting - パイプライン中にテスト ケースを実行するかどうかを選択できます。
- AnalyzePolicy - パイプライン プロセスで使用されるワークフロー アナライザーのルールを保持するガバナンス ポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
- SkipValidation - パッケージの構築前の検証をスキップできます。この値は既定では無効化されています。
- FirstOrchestratorFolder - 構築されたパッケージのパブリッシュ先 Orchestrator のフォルダーです。
- FirstOrchestratorUrl - 構築されたパッケージのパブリッシュ先 Orchestrator の URL です。
- SecondOrchestratorFolder - 構築されたパッケージの承認後のパブリッシュ先 Orchestrator のフォルダーです。
- SecondOrchestratorUrl - 構築されたパッケージの承認後のパブリッシュ先 Orchestrator の URL です。
- TestingFolder - テストが実行される Orchestrator のフォルダーです。
- HaveSamePackageFeed - このフィールドは、既定で「False」に設定されます。1 つ目の環境と 2 つ目の環境で同じパッケージ/ライブラリ フィードを使用している場合は、これを「True」に設定します。
- Build.and.publish
- AnalyzePolicy - パイプライン プロセスで使用されるワークフロー アナライザーのルールを保持するガバナンス ポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
- SkipValidation - パッケージの構築前の検証をスキップできます。この値は既定では無効化されています。
- OrchestratorUrl - 構築されたパッケージのパブリッシュ先 Orchestrator の URL です。
- OrchestratorFolder - 構築されたパッケージのパブリッシュ先 Orchestrator のフォルダーです。
- Copy.package.between.environments
- PackageName - コピーするパッケージの名前です。
- IsLibrary - パッケージがライブラリかどうかを定義します。
- PackageVersion - コピーするパッケージのバージョンです。
- SourceOrchestratorFolder - パッケージのコピー元の Orchestrator のフォルダーです。
- SourceOrchestratorUrl - パッケージのコピー元の Orchestrator への URL です。
- DestinationOrchestratorUrl - パッケージのコピー先 Orchestrator の URL です。
- DestinationOrchestratorFolder - パッケージのコピー先 Orchestrator のフォルダーです。
- Update.process.from.code
- ProcessName - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
- AnalyzePolicy - パイプライン プロセスで使用されるワークフロー アナライザーのルールを保持するガバナンス ポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
- SkipValidation - パッケージの構築前の検証をスキップできます。この値は既定では無効化されています。
- OrchestratorUrl - 更新するパッケージがある Orchestrator への URL です。
- OrchestratorFolder - 更新するパッケージがある Orchestrator のフォルダーです。
- Update.with.tests
- ProcessName - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
- AnalyzePolicy - パイプライン プロセスで使用されるワークフロー アナライザーのルールを保持するガバナンス ポリシーです。空のままにすると、プロジェクトの分析はスキップされます。
- SkipTesting - パッケージの構築前のテストをスキップできます。この値は既定では無効化されています。
- OrchestratorUrl - 更新するパッケージがある Orchestrator への URL です。
- OrchestratorFolder - 更新するパッケージがある Orchestrator のフォルダーです。
- OrchestratorTestingFolder - パイプラインで使用するテストがある Orchestrator のフォルダーです。
構築予定のオートメーション プロジェクトと、パイプライン プロセスを実行するマシンとの間には、相互運用性の要件があります。
正しいマッピングは次のとおりです。
- Windows - レガシ プロジェクト → ビルド OS: Windows のみ
- Windows プロジェクト→ ビルド OS: Windows のみ
- クロスプラットフォーム プロジェクト→ ビルド OS: Windows または Linux
Automation Ops™ には、パイプライン プロセス用に次の既定の引数セットが用意されています。
| 名前 | 方向 | 引数の型 | 説明 |
|---|---|---|---|
| BuildNumber | In | 文字列 | パイプライン ジョブの実行ごとに一意の数です。 |
| RepositoryUrl | In | 文字列 | リポジトリの URL です。通常は [Clone] アクティビティで使用されます。 |
| CommitSha | In | 文字列 | コミットの識別子です。 |
| プロジェクト パス | In | 文字列 | project.json ファイルへのパスです。[構築] アクティビティで使用できます。 |
| ComitterUsername | In | 文字列 | コミットをトリガーするユーザーのユーザー名です。 |
|
RepositoryType |
In |
文字列 |
リポジトリの種類 (git など)。 |
|
RepositoryBranch |
In |
文字列 |
使用されるリポジトリブランチ。 |
パイプラインが実行されるたびにログが生成されます。 ログは Automation Ops™ で確認できます。また、パイプラインが実行されるたびに Orchestrator でジョブが作成されるため、Orchestrator でも確認できます。
- Automation Ops™ で、パイプラインの右側にカーソルを合わせて、コンテキスト メニューから [ ログを表示] を選択します。
- Orchestrator で、専用のパイプライン フォルダー > [自動化] > [ジョブ] にアクセスします。[ソース] 列で、[パイプライン] タグを探し、[ログを表示] を選択します。
作成時にコミットごとにパイプラインが実行されるよう設定されている場合は、GitHub/Azure DevOps 内に Webhook が自動的に作成されています。
パイプラインを含むソース管理のリンクがすでに削除されている場合は、ランタイムの設定を削除した後に Webhook を手動で削除してください。Webhook を削除しなくても CI/CD サービスの機能に影響はありませんが、この手順を実行することをお勧めします。
コミット時にトリガーされ、ソース管理の接続が削除されたパイプラインごとに、GitHub/Azure DevOps のリポジトリにアクセスし、ランタイム環境を削除した後に Webhook を削除する必要があります。
組織内でソース管理接続が既に削除されており、そのリポジトリが現在別の UiPath 組織に接続されている場合、有効な Webhook を 2 番目の組織から削除する可能性があります。 これらは削除しないでください。削除しないと、コミット時にパイプラインがトリガーされません。
したがって、Webhook を削除する前に UiPath 組織において、現在のリポジトリが有効な CI/CD ランタイムの設定内に有効な接続を有していないことを確認してください。
GitHub リポジトリから Webhook を削除するには、以下の手順を実行します。
- Github リポジトリに移動し、[ 設定] > [Webhooks] を選択します。
/roboticsops_/cicd_/api/webhooks/github/pipelineで終わる Webhook URL をすべて削除します。
