Automation Ops
最新
バナーの背景画像
Automation Ops ユーザー ガイド
最終更新日 2024年3月1日

UiPath Automation Ops - パイプライン

Automation Ops - パイプラインを使用すると、GitHub でオートメーション プロジェクトのコードを管理するための継続的インテグレーション/継続的デリバリー システムを簡単に設定できます。

パイプラインには、お使いの環境でコードの変更に使用されるオートメーション プロセスに応じた一連のステップが含まれています。これらのプロセス (パイプライン プロセスとも呼ばれます) では、Automation Ops - パイプライン アクティビティ パッケージを使用します。ユーザーがこれらのパイプライン プロセスを表示するには、そのプロセスを含む 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 内の専用パイプライン フォルダーを削除すると、そのフォルダーに関連付けられているすべてのパイプラインが中断されます。

初期設定

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

注:

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

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

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

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

  • テナント: PipelinesTenantRole、Allow to be Automation User、Allow to be Automation Publisher
  • Pipelines フォルダー: PipelinesFolderRole、Automation User、Automation Publisher
注:

パイプライン用に作成したロボット アカウントが、対象の Orchestrator フォルダーにも割り当てられていることを確認してください。 パイプラインはそのアカウントで動作するために必要です。 詳しくは、「 アカウントのアクセス権を設定する」をご覧ください。

また、既定で、以下の定義済みパイプライン プロセスを利用できます。

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 - 更新するプロセスの名前です。プロジェクトがプロセスの場合にのみ使用されます。
重要:

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

For example, a project created using Windows-Legacy or Windows compatibility cannot be built on a Cloud Serverless robot. You must use a Windows based machine instead.
When running a pipeline which generates and publishes a process using Integration Service connections, make sure that all necessary project folders are committed to your source control provider. For example, it is necessary when initializing git from Studio, to commit all associated project folders, such as .settings, .project, .tmh.

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

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

次の手順を実行します。

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

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


  5. [保存して実行] タブで、以下を設定します。
    • プロジェクト名 - パイプライン プロジェクトの名前を入力します。既定では、この名前は GitHub リポジトリの名前とパイプライン オートメーション プロジェクトの名前で構成されます。
    • 説明 - 必要に応じて説明を追加します。
    • パイプラインの実行方法 - パイプラインの実行方法を以下から選択します。
      • コミットのたびに実行 - パイプライン オートメーションは、選択したプロジェクトの GitHub リポジトリのコードが変更されるたびにトリガーされます。
      • 手動で実行 - パイプライン オートメーションは手動でトリガーされます。
  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 を手動で削除する必要があります。 これらを削除しなくても CiCd サービスの機能に影響はありませんが、この手順を推奨しました。

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

重要:

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

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

docs image

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

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

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

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

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

  1. Azure DevOps リポジトリに移動し、プロジェクトの [プロジェクト設定 ] > [ サービス フック] を選択します。
  2. 削除する Webhook で、[ Edit] を選択します。
    docs image
  3. Webhook が /roboticsops_/cicd_/api/webhooks/azure/pipelineで終了していることを確認してください。
    docs image
    docs image
  4. Webhook を削除します。
    docs image

Was this page helpful?

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