automation-ops
latest
false
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。
UiPath logo, featuring letters U and I in white
Automation Ops ユーザー ガイド
Automation CloudAutomation Cloud Public SectorAutomation Suite
Last updated 2024年10月23日

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 での特定の構成が必要になります。 この構成を Pipelines ランタイム環境と呼びます。

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

複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新

これらの既定のパイプライン プロセスには、独自の引数セットが用意されています。たとえば、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 の [テンプレート] タブにあるテンプレートを使用して、パイプラインの操作を開始することもできます。
docs image
次のテンプレートを使用できます。
  • Build and promote with approval pipeline:
    • 使用法: オートメーション プロジェクトの開始から承認までの管理。

    • 手順: 複製、分析、テストの実行、ビルド、パッケージのパブリッシュ、プロセスの更新、承認、パッケージのダウンロード、パッケージのアップロード、およびパッケージの更新。

  • Update process from a code line:
    • 使用法:進行中のプロセスの更新と変更のための合理化された手順を強調します。

    • 手順: 複製、分析、ビルド、パッケージのパブリッシュ、更新プロセス

重要:

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

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

たとえば、相互運用性を Windows - レガシまたは Windows に設定して作成されたプロジェクトを Cloud ロボット - サーバーレス上に構築することはできません。代わりに、Windows ベースのマシンを使用する必要があります。
Integration Service のコネクションを使用してプロセスを生成およびパブリッシュするパイプラインを実行する場合は、必要なすべてのプロジェクト フォルダーがソース管理プロバイダーにコミットされていることを確認してください。 たとえば、Studio から git を初期化するときに、 .settings.project.tmhなどの関連するプロジェクト フォルダーすべてをコミットする必要があります。

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

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

次の手順を実行します。

  1. Automation Cloud™ で、左側のナビゲーション バーから [Automation Ops™ > パイプライン ] に移動します。
  2. [新しいパイプライン] を選択します。外部リポジトリがソース管理に接続されている場合は、そこにも自動的に接続されます。
    手記: 1 つの GitHub 組織に同時に接続できる UiPath® Automation Cloud™ の組織は 1 つだけです。
  3. [場所] タブで、外部リポジトリの組織、リポジトリ、ブランチ、およびオートメーション プロジェクト (任意) を選択します。[次へ] をクリックします。

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


  5. [保存して実行] タブで、以下を設定します。
    • プロジェクト名 - パイプライン プロジェクトの名前を入力します。既定では、この名前はリポジトリの名前とパイプライン オートメーション プロジェクトの名前で構成されます。
    • 説明 - 必要に応じて、説明を追加します。
    • パイプラインの実行方法 - パイプラインの実行方法を以下から選択します。
      • コミットのたびに実行 - パイプライン オートメーションは、選択したプロジェクトのリポジトリのコードが変更されるたびにトリガーされます。
      • 手動で実行 - パイプライン オートメーションは手動でトリガーされます。
        注:
        手動でトリガーされるパイプラインでは、ジョブの開始時に使用されるコミットは、選択した project.json ファイルのフォルダーでの最新のコミットです。

        そのコミットでフォルダー内のファイルが変更されていない場合、リポジトリ全体の最新のコミットではありません。

  6. [保存] をクリックしてパイプラインを保存するか、[保存して実行] をクリックしてパイプラインを保存し、実行します。
重要:

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

ProjectPath 引数には、パイプラインの設定の手順 [場所] の [オートメーション プロジェクト (任意)] フィールドで選択した値が入力されます。
フィールドを空白のままにすると、プロセスの 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

複製 -> 分析 -> テストを実行 -> 構築 -> パッケージをパブリッシュ -> プロセスを更新 -> 承認 -> パッケージをダウンロード -> パッケージをアップロード -> プロセスを更新

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

  • 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™ には、パイプライン プロセス用に次の既定の引数セットが用意されています。

名前方向引数の型説明
BuildNumberIn文字列パイプライン ジョブの実行ごとに一意の数です。
RepositoryUrlIn文字列リポジトリの URL です。通常は [Clone] アクティビティで使用されます。
CommitShaIn文字列コミットの識別子です。
プロジェクト パスIn文字列project.json ファイルへのパスです。[構築] アクティビティで使用できます。
ComitterUsernameIn文字列コミットをトリガーするユーザーのユーザー名です。

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 ランタイムの設定内に有効な接続を有していないことを確認してください。

docs image

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

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

  1. Github リポジトリに移動し、[ 設定] > [Webhooks] を選択します。
    docs image
  2. /roboticsops_/cicd_/api/webhooks/github/pipelineで終わる Webhook URL をすべて削除します。
    docs image

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

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

  1. Azure DevOps リポジトリに移動し、[Project Settings] > [Service Hooks] を選択します。
  2. 削除する Webhook で、[Edit] を選択します。
    docs image
  3. Webhook URL の末尾が /roboticsops_/cicd_/api/webhooks/azure/pipeline であることを確認します。
    docs image
    docs image
  4. Webhook URL を削除します。
    docs image

このページは役に立ちましたか?

サポートを受ける
RPA について学ぶ - オートメーション コース
UiPath コミュニティ フォーラム
Uipath Logo White
信頼とセキュリティ
© 2005-2024 UiPath. All rights reserved.