- リリース ノート
- はじめに
- ガバナンス
- ソース管理
- CI/CD パイプライン
- フィードの管理
- ログ
UiPath Automation Ops - パイプライン
Automation Ops - パイプラインを使用すると、Github や Azure DevOps などの外部リポジトリで、オートメーション プロジェクトのコードを管理するための継続的インテグレーション/継続的デリバリー システムを簡単に設定できます。
パイプラインには、お使いの環境でコードの変更に使用されるオートメーション プロセスに応じた一連のステップが含まれています。これらのプロセス (パイプライン プロセスとも呼ばれます) では、Automation Ops - パイプライン アクティビティ パッケージを使用します。ユーザーがこれらのパイプライン プロセスを表示するには、そのプロセスを含む Orchestrator フォルダーへのアクセス権が必要です。
パイプラインがトリガーされると、Unattended ロボットを使用して関連するパイプライン プロセスを実行するジョブが開始されます。
- Robot のバージョン:
- 2021.10 および 2022.4:
.NET Desktop Runtime 6.0.*は、ロボット端末に手動でインストールする必要があります。 - 2022.8 以降:
.NET Desktop Runtimeはロボットとともに自動的にインストールされます。
- 2021.10 および 2022.4:
- プロセスの詳細:
Orchestrator の基本構成には、パイプライン プロセスとロボット アカウントを含む専用フォルダーと、パイプライン ジョブを実行するためのマシンまたはマシン テンプレートが含まれます。
The robot account created during the quick setup is essential. All the pipelines (Orchestrator jobs) are ran on its behalf. Deleting the robot account causes an invalid pipeline runtime configuration and the need to rerun the quick setup.
Orchestrator 内の専用パイプライン フォルダーを削除すると、そのフォルダーに関連付けられているすべてのパイプラインが中断されます。
Automation Ops - パイプラインを初めて設定する際に、クイック セットアップ ウィンドウが表示され、今後のパイプラインを実行するテナントとマシンの種類を選択できます。実際の環境の既存マシンを使用するか、「PipelinesRobot」という名前の新しいサーバーレス マシンを自動的に作成することができます。
新しいサーバーレス マシンを作成する場合は、テナントで十分なロボット ユニットが利用可能であることを確認してください。
クイック セットアップでは、「パイプライン」という名前の新しいフォルダーと以下のロールが自動的に作成されます。
- パイプラインのテナント ロール
- パイプラインのフォルダー ロール
パイプライン ロボットには、以下のロールが自動的に割り当てられます。
- テナント: PipelinesTenantRole、Allow to be Automation User、Allow to be Automation Publisher
- Pipelines フォルダー: PipelinesFolderRole、Automation User、Automation Publisher
パイプライン用に作成したロボット アカウントが、対象の Orchestrator フォルダーにも割り当てられていることを確認してください。 パイプラインはそのアカウントで動作するために必要です。 詳しくは、「 アカウントのアクセス権を設定する」をご覧ください。
The Run Tests activity runs the tests in the provided Orchestrator folder. The Pipelines robot account publishes the package in the respective folder, but the tests can be run by any robot account in that folder that qualifies for the test run, not only by the Pipelines robot account.
また、既定で、以下の定義済みパイプライン プロセスを利用できます。
|
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 - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
When using the Build activity, validate the compatibility requirements between the automation projects you are building and the machine running the process.
Windows ベースのマシンを使用する必要があります。
.settings、 .project、 .tmhなどの関連するプロジェクト フォルダーすべてをコミットする必要があります。
Orchestrator の設定が完了したら、Automation Ops -パイプライン、コードを保持する GitHub リポジトリ、および Orchestrator パイプラインのランタイム環境との初期連携を設定する必要があります。その際、最初のパイプラインも作成します。
次の手順を実行します。
- Automation Cloud で、左側のナビゲーション バーから [Automation Ops] > [パイプライン] に移動します。
- [新しいパイプライン] を選択します。外部リポジトリがソース管理に接続されている場合は、そこにも自動的に接続されます。
注: 1 つの GitHub 組織に同時に接続できる UiPath Automation Cloud の組織は 1 つだけです。
- [場所] タブで、外部リポジトリの組織、リポジトリ、ブランチ、およびオートメーション プロジェクト (任意) を選択します。[次へ] をクリックします。
- [パイプラインの定義] タブで、以下の手順を実行します。
- パイプライン プロセスを選択します。パイプライン プロセスに引数が用意されている場合は、その値を追加できます。
- [保存して実行] タブで、以下を設定します。
- プロジェクト名 - パイプライン プロジェクトの名前を入力します。既定では、この名前はリポジトリの名前とパイプライン オートメーション プロジェクトの名前で構成されます。
- 説明 - 必要に応じて、説明を追加します。
- パイプラインの実行方法 - パイプラインの実行方法を以下から選択します。
- コミットのたびに実行 - パイプライン オートメーションは、選択したプロジェクトのリポジトリのコードが変更されるたびにトリガーされます。
- 手動で実行 - パイプライン オートメーションは手動でトリガーされます。
- [保存] をクリックしてパイプラインを保存するか、[保存して実行] をクリックしてパイプラインを保存し、実行します。
手順 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 を手動で削除する必要があります。 これらを削除しなくても 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 をすべて削除します。
