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 はロボットとともに自動的にインストールされます。
• プロセスの詳細:
  • パイプライン プロセスは、バックグラウンド プロセスとして実行するように設定する必要があります。この操作は、Studio のプロジェクト設定メニューから実行します。バックグラウンド プロセスについて詳しくは、こちらをご覧ください。
  • パイプライン プロセスを Studio から Orchestrator にパブリッシュする場合は、必ず [パブリッシュのオプション] セクションで [ソースを含める] も選択してください。オートメーション プロジェクトのパブリッシュについて詳しくは、こちらをご覧ください。

構成

Automation Ops™ - パイプラインは、Unattended ロボットを使用してパイプライン プロセスを実行することで機能します。つまり、パイプラインを使用する前に Orchestrator で特定の設定を行う必要があります。この構成は、 パイプライン ランタイム環境と呼ばれます。

Orchestrator の基本構成には、パイプライン プロセスとロボット アカウントを含む専用フォルダーと、パイプライン ジョブを実行するためのマシンまたはマシン テンプレートが含まれます。

重要:

クイック セットアップ時に作成したロボット アカウントは必須です。すべてのパイプライン (Orchestrator のジョブ) が代わりに実行されます。ロボット アカウントを削除すると、パイプライン ランタイムの設定が無効になり、クイック セットアップを再実行する必要があります。Orchestrator の専用のパイプライン フォルダーを削除すると、関連付けられているすべてのパイプラインが破損します。

初期設定

Automation Ops™ - パイプラインを初めて設定する際に、クイック セットアップ ウィンドウが表示され、今後のパイプラインを実行するテナントとマシンの種類を選択できます。 実際の環境の既存マシンを使用するか、「PipelinesRobot」という名前の新しいサーバーレス マシンを自動的に作成することができます。

注:

新しいサーバーレス マシンを作成する場合は、テナントで十分なロボット ユニットが利用可能であることを確認してください。

クイック セットアップでは、「パイプライン」という名前の新しいフォルダーと以下のロールが自動的に作成されます。

• パイプラインのテナント ロール
• パイプラインのフォルダー ロール

パイプライン ロボットには、以下のロールが自動的に割り当てられます。

• テナント: パイプラインのテナント ロール、Allow to be Automation User、Allow to be Automation Publisher
• パイプライン フォルダー: パイプライン フォルダー ロール、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	複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新

これらの既定のパイプライン プロセスには、独自の引数セットが用意されています。たとえば、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 - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。

UiPath Studio および Studio Web のテンプレート ([テンプレート] タブ) を使用してパイプラインの作業を開始することもできます。

次のテンプレートを使用できます。

• Build and promote with approval pipeline:

  • 使用法: オートメーション プロジェクトの開始から承認までの管理。
  • 手順: 複製、分析、テストの実行、ビルド、パッケージのパブリッシュ、プロセスの更新、承認、パッケージのダウンロード、パッケージのアップロード、およびパッケージの更新。

• Update process from a code line:

  • 使用法:進行中のプロセスの更新と変更のための合理化された手順を強調します。
  • 手順: 複製、分析、ビルド、パッケージのパブリッシュ、更新プロセス

重要:

初期設定で作成された Cloud サーバーレス ロボットは 標準 サイズです。[テストを実行] アクティビティを使用する際に、Cloud サーバーレス ロボットを含む Orchestrator フォルダーが含まれる場合は、ロボットが標準サイズであることを確認してください。

[Build] アクティビティを使用するときは、構築しているオートメーション プロジェクトとプロセスを実行しているマシンとの相互運用性の要件を検証してください。

たとえば、Windows-Legacy or Windows 対応 OS を使用して作成されたプロジェクトを Cloud ロボット - サーバーレス上に構築することはできません。代わりに、 Windows ベースのマシンを使用する必要があります。

Integration Service のコネクションを使用してプロセスを生成およびパブリッシュするパイプラインを実行する場合は、必要なすべてのプロジェクト フォルダーがソース管理プロバイダーにコミットされていることを確認してください。 たとえば、Studio から git を初期化するときに、 .settings、 .project、 .tmhなどの関連するプロジェクト フォルダーすべてをコミットする必要があります。

最初のパイプラインを作成する

Orchestrator の設定が完了したら、Automation Ops™ - パイプライン、コードを保持する GitHub リポジトリ、および Orchestrator パイプラインのランタイム環境との初期連携を設定する必要があります。 その際、最初のパイプラインも作成します。

次の手順を実行します。

1. Automation Cloud™ で、左側のナビゲーション バーから [Automation Ops™ ] > [ パイプライン ] に移動します。

2. [ 新しいパイプライン] を選択します。外部リポジトリが ソース管理に接続されている場合は、自動的に接続されます。

   注:

   GitHub 組織に同時に接続できる UiPath® Automation Cloud™ 組織は 1 つだけです。

3. [ 場所 ] タブで、外部リポジトリの組織、リポジトリ、ブランチ、およびオートメーション プロジェクト (任意) を選択します。[ 次へ] を選択します。

   

4. [ パイプラインの定義 ] タブで、パイプライン プロセスを選択します。パイプライン プロセスに引数が用意されている場合は、その値を追加できます。
   

5. [保存して実行] タブで、以下を設定します。

   • プロジェクト名 - パイプライン プロジェクトの名前を入力します。既定では、この名前はリポジトリの名前とパイプライン オートメーション プロジェクトの名前で構成されます。
   • 説明 - 必要に応じて、説明を追加します。
   • パイプラインの実行方法 - パイプラインの実行方法を以下から選択します。
     • コミットのたびに実行 - パイプライン オートメーションは、選択したプロジェクトのリポジトリのコードが変更されるたびにトリガーされます。
     • 手動で実行 - パイプライン オートメーションは手動でトリガーされます。
       注:

       手動でトリガーされるパイプラインでは、ジョブの開始時に使用されるコミットは、選択した project.json ファイルのフォルダーに対する最新のコミットです。リポジトリ内のファイルがそのコミットで変更されていない場合、リポジトリ全体の最新のコミットではありません。

6. パイプラインを保存するには [ 保存 ] を選択し、パイプラインを保存して実行するには [ 保存して実行 ] を選択します。

重要:

手順 1 でリポジトリの特定のプロセスが選択されておらず (オートメーション プロジェクトが選択されていない)、 パイプラインがコミットによってトリガーされるように設定されている場合、パイプラインはリポジトリ内の任意のコミットによってトリガーされます。

ProjectPath 引数に、パイプライン設定の [場所] ステップの [Automation project (optional)場所] フィールドで選択した値が入力されます。フィールドを空白のままにすると、プロセスの ProjectPath 引数は空のままになります。このシナリオは、オートメーション プロジェクトが 1 つのみであるリポジトリに使用できます。

パイプラインを手動で実行する

1. Automation Cloud™ で、左側のナビゲーション バーから [Automation Ops™ ] に移動します。
2. [パイプライン] を選択します。 利用可能なパイプラインが表示されます。
3. パイプラインを選択し、[ 新しいジョブの開始] を選択します。これによりパイプラインの実行がトリガーされ、各ステップの進行状況をリアルタイムで確認できます。

[ パイプラインの設定] を選択してパイプラインを編集することもできます。パイプラインの概要が表示され、以下の操作を実行できます。

• パイプラインを編集 - パイプラインを更新する場合に選択します。更新できるのは、パイプラインの名前、説明、トリガーの種類、およびカスタム パイプラインの引数のみです。場所とパイプラインの定義は変更できません。
• パイプラインを削除 - パイプラインを削除する場合に選択します (パイプラインに関連する情報はすべて削除されます)。

定義済みのパイプライン プロセス

以下の表では、既定で使用できる定義済みのパイプライン プロセスについて説明します。

Build.and.publish	複製 -> 分析 -> 構築 -> パブリッシュ
Copy.package.between.environments	パッケージをダウンロード -> パッケージをパブリッシュ
Update.process.from.code	複製 -> 分析 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新
Update.with.tests	複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新
Build.and.promote.with.approval	複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新

定義済みのパイプライン テンプレートの最新バージョンは、 Marketplace で入手できます。

これらの既定のパイプライン プロセスでは、次の一連の引数を利用できます。

• 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 で、専用のパイプライン フォルダー > [自動化] > [ジョブ] にアクセスします。[ソース] 列で、[パイプライン] タグを探し、[ログを表示] を選択します。

Webhook を手動で削除する

作成時にコミットごとにパイプラインが実行されるよう設定されている場合は、GitHub/Azure DevOps 内に Webhook が自動的に作成されています。

パイプラインを含むソース管理のリンクがすでに削除されている場合は、ランタイムの設定を削除した後に Webhook を手動で削除してください。Webhook を削除しなくても CI/CD サービスの機能に影響はありませんが、この手順を実行することをお勧めします。

コミット時にトリガーされ、ソース管理の接続が削除されたパイプラインごとに、GitHub/Azure DevOps のリポジトリにアクセスし、ランタイム環境を削除した後に Webhook を削除する必要があります。

重要:

組織内でソース管理接続が既に削除されており、そのリポジトリが現在別の UiPath 組織に接続されている場合、有効な Webhook を 2 番目の組織から削除する可能性があります。 これらは削除しないでください。削除しないと、コミット時にパイプラインがトリガーされません。

したがって、Webhook を削除する前に UiPath 組織において、現在のリポジトリが有効な CI/CD ランタイムの設定内に有効な接続を有していないことを確認してください。

GitHub リポジトリから Webhook を削除する

GitHub リポジトリから Webhook を削除するには、以下の手順を実行します。

1. Github リポジトリに移動し、[ Settings ] > [ Webhook] を選択します。

   

2. /roboticsops_/cicd_/api/webhooks/github/pipelineで終わる Webhook URL をすべて削除します。

   

Azure DevOps リポジトリから Webhook を削除する

Azure DevOps リポジトリから Webhook を削除するには、以下の手順を実行します。

1. Azure DevOps リポジトリに移動し、[Project Settings] > [Service Hooks] を選択します。

2. 削除する Webhook で、[Edit] を選択します。

   

3. Webhook URL の末尾が /roboticsops_/cicd_/api/webhooks/azure/pipeline であることを確認します。

   

   

4. Webhook URL を削除します。