方法: ソリューションをパッケージ化してパブリッシュする

バージョンのピン留めとロールバックのガイダンスを使用して、開発、ステージング、運用の各環境にわたって UiPath ソリューションをパッケージ化してパブリッシュします。

このページでは、 最初のパイプライン が停止する場所を取り上げます。これは、既に 1 つのテナントで 3 つのコマンド フローが機能しており、 開発→段階→ production に同じソリューションを出荷し、再現性のためにバージョンをピン留めし、悪いリリースを取り消す方法を正確に知っていることを前提としています。

ソリューションをエンドツーエンドでまだパックしていない場合は、まず「 最初のパイプライン 」をお読みください。ここにあるすべてのパイプラインは、 uip solution pack / publish / deploy runに基づいて構築されています。

このガイドの内容

• Orchestrator フィードと相性の良い バージョン管理の規範 です。
• 再パッケージ化せずに複数のテナントで同じパッケージを昇格させる。
• CLIとそのツールをピン留めして、すべてのビルドを再現できるようにします。
• とuip solution packages delete を使用して破損したリリースをuip solution deploy uninstall ロールバック します。

バージョンを選択して固定する

uip solution pack --version 、 .zip ファイル名と、すべての下流工程で消費される packageVersion の両方を制御します。デフォルトは 1.0.0です。実際のパイプラインは、それを明示的に渡す必要があります。

セマンティック バージョニング (MAJOR.MINOR.PATCH) は、Orchestrator フィードが最適に並べ替えるスキームです。2つの具体的なルールが、クリーンな歴史とソート不可能な歴史の違いを生む。

1. 特定のバージョンを再利用しないでください。uip solution publish は、フィードに既に存在するname+versionペアを却下します。拒否された公開は、 packを再実行して「修正」するものではなく、ビルドバグとして扱います。
2. バージョン コアのタイムスタンプではなく、ビルド メタデータを使用します。1.2.0.20260424よりも1.2.0-rc.3を優先します。前者はフィード内で正しくソートされます。後者は技術的には妥当なSemverですが、一目で読みにくいです。

一般的な CI 構成:

# Build number from the pipeline, tag from git, combined for a valid pre-release
VERSION="1.2.0-ci.${BUILD_NUMBER}"

uip solution pack ./my-solution ./dist \
  --name my-solution \
  --version "$VERSION"

uip solution publish "./dist/my-solution_${VERSION}.zip"

.zipパスは決定論的 (<outputDir>/<name>_<version>.zip) (uip solution pack を参照) であるため、スクリプトは JSON を解析せずにパスを計算できます。

1 つのパッケージをテナント間で昇格する

バージョンごとに 1 回パックしてパブリッシュした後、同じ成果物を各テナントに再デプロイします。環境ごとに再梱包すると、ドリフトのリスクがあります。同じバージョンを再公開することも (name, version)ごとのべき等であるため、誤って2回公開しても何も壊れません。それでも、1 つのビルド = 1 つのパブリッシュが最もクリーンなコントラクトです。

CI の昇格ジョブの場合は、アクティブなセッションのテナントを を使用して反復間で切り替え uip login tenant set <tenant>、セッションが現在バインドされているテナントに対して publish/deploy run を実行します。

VERSION="$1"   # e.g. 1.2.0-ci.456

for tenant in dev stage prod; do
  uip login tenant set "$tenant"

  uip solution publish "./dist/my-solution_${VERSION}.zip"

  uip solution deploy run \
    --name "my-solution-${tenant}" \
    --package-name my-solution \
    --package-version "$VERSION" \
    --folder-name MySolution \
    --parent-folder-path Shared
done

2つのメモ:

• publish はテナントごとのべき等です。同じ (name, version) を 2 回パブリッシュすると、既存の PackageVersionKey が複製されるのではなく、返されるようになりました。詳しくは、「 uip solution publish」をご覧ください。
• デプロイ名はテナントを対象範囲にする必要があります。my-solution ではなく my-solution-prod を使用すると、uip solution deploy listが読みやすくなり、環境をまたいだ偶発的なdeploy uninstall呼び出しが防止されます。--name フォルダーではなく、デプロイ レコードを識別します。

環境ごとの構成をパラメーター化する

ソリューションにテナントごとに異なるリソース (キュー、アセット) がある場合は、構成ファイルを一度生成し、 deploy config setを使用して環境ごとに編集します。

uip login tenant set prod

uip solution deploy config get my-solution --package-version "$VERSION" -d ./deploy-config.json

# Production uses a bigger retry count
uip solution deploy config set ./deploy-config.json MyQueue maxNumberOfRetries 5

uip solution deploy run \
  --name my-solution-prod \
  --package-name my-solution \
  --package-version "$VERSION" \
  --folder-name MySolution \
  --parent-folder-path Shared \
  --config-file ./deploy-config.json

新しく deploy config link作成した Orchestrator リソースではなく、既存の Orchestrator リソースを渡します。

uip solution deploy config link ./deploy-config.json MyQueue \
  --name SharedProductionQueue \
  --folder-path "Shared/Production"

デプロイを新しいバージョンにアップグレードする

deploy runは常に新しいフォルダー内に新しいデプロイが作成されます。同じ--nameで再度実行しても、既存のデプロイは更新されません。これは失敗します (-y, --yes渡さない限り)、最初のコピーと並んで 2 番目の独立したコピーがインストールされます。ライブ デプロイを新しいパッケージ バージョンに移行するには、代わりに uip solution deploy upgrade を使用します。デプロイのフォルダー、プロビジョニングされたリソース、およびそれらに既に設定されている設定 (資格情報アセットのシークレットなど) が保持されます。

まず、 でデプロイのキーを見つけますdeploy list

uip login tenant set prod

DEPLOYMENT_KEY=$(uip solution deploy list \
  --output-filter "Data[?Name=='my-solution-prod'] | [0].Key" --output plain)

次に、アップグレードします。

uip solution deploy upgrade "$DEPLOYMENT_KEY" --version 1.3.0

現在、アップグレード ターゲットとしてサポートされているのは、最新のパブリッシュ済みバージョンのみです。Pass --no-wait アップグレードが完了するのを待つのではなく、アップグレードが受け入れられたらすぐに戻るようにします。同じメカニズムが逆に機能し、不適切なリリースを元に戻します — ロールバックを参照してください。

CLIとそのツールをピン留めする

再現可能なパイプラインは、依存するすべてのツールをピン留めします。CLI は npm で @uipath/cliとして配布されます。 uip solution … は @uipath/solution-toolによって提供されます。どちらもsemverに従います。

# Pin the CLI exactly
npm install -g @uipath/cli@1.0.0

# Pre-install tools explicitly so the first command is not slower than the rest
uip tools install @uipath/solution-tool @uipath/orchestrator-tool

ツールのバージョンは、デフォルトでCLIのMAJORを追跡します。MINOR行なので、通常はCLIだけを固定するだけで十分です。パッチごとの厳密な再現性を得るには、ツールも固定します。

uip tools install @uipath/solution-tool@1.0.2

詳しくは、「 Scripting patterns — Pinning versions in CI 」および「 Installing UiPath CLI — CI/CD 」をご覧ください。

ロールバック

生産を壊すことはめったにありません。重要なときにロールバックします。ロールバックには、 正常なバージョンを再デプロイ する(高速)と 、不良アーティファクトを削除する (クリーン)という2つのレベルがあります。

高速: デプロイを以前のバージョンに戻します

不正なデプロイが稼働している場合は、最初にアンインストールするのではなく、 deploy upgrade を使用して、正常な最後のバージョンに戻します。 deploy upgrade では、現在は 最新のパブリッシュ済みバージョン のみがターゲットとしてサポートされるため、このパスでは、以前のバージョンがフィード内の最新のバージョンである (または再パブリッシュされている) と仮定します。

uip login tenant set prod

DEPLOYMENT_KEY=$(uip solution deploy list \
  --output-filter "Data[?Name=='my-solution-prod'] | [0].Key" --output plain)

uip solution deploy upgrade "$DEPLOYMENT_KEY" --version 1.1.9

これは一般的なケースです。フォルダーにプロビジョニングされたリソースはそのまま残され、既存の設定が再利用されます。

クリーン: デプロイをアンインストールします。

ソリューションに不要なリソース (キュー、アセット、トリガー) がプロビジョニングされている場合は、 uip solution deploy uninstallを 呼び出します。これは元に戻すことができないため、-y, --yesが必要です。

uip login tenant set prod

uip solution deploy uninstall my-solution-prod --yes

これにより、プロビジョニングされたすべてのリソースとソリューション フォルダーが削除されます。これは破壊的な操作です。特にテナントのループで実行する場合は、実行する前にデプロイ名を deploy list で確認してください。

成果物を廃止する

不正なバージョンを参照しているものがなくなったら、 uip solution packages deleteを使用してテナント フィードから削除します。

uip login tenant set prod

uip solution packages delete my-solution 1.2.0-ci.456 --yes

論理的な削除はありません。これは永続的です。削除は小さなウィンドウにとどめてください — このコマンドは一度に 1 つの packageVersion のみを受け入れるため、一括クリーンアップのスクリプトには list → filter → xargs パターンが必要です。完全な例については、 packages delete リファレンスをご覧ください。

持っているものを確認する

上記のいずれかの前に、グラウンドトゥルースを入手してください。

# What is in the feed?
uip solution packages list --limit 50 \
  --output-filter "Data[?packageName=='my-solution']"

# What is deployed?
uip solution deploy list --folder-path Shared --limit 50

CI 対応スニペット

ステップの組み合わせ — すべてのCIシステムがそのまま実行できるシェルスクリプト:

#!/usr/bin/env bash
set -euo pipefail

VERSION="$1"                          # e.g. 1.2.0-ci.456
SOLUTION_DIR="./my-solution"
OUT_DIR="./dist"

# 1. Log in (External App in CI)
uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant "$UIPATH_TENANT_DEV"

# 2. Pack once
uip solution pack "$SOLUTION_DIR" "$OUT_DIR" \
  --name my-solution \
  --version "$VERSION"

PKG="${OUT_DIR}/my-solution_${VERSION}.zip"

# 3. Publish + deploy to each tenant
for env_name in dev stage prod; do
  tenant_var="UIPATH_TENANT_$(echo "$env_name" | tr a-z A-Z)"
  tenant="${!tenant_var}"

  uip login tenant set "$tenant"

  uip solution publish "$PKG"
  uip solution deploy run \
    --name "my-solution-${env_name}" \
    --package-name my-solution \
    --package-version "$VERSION" \
    --folder-name MySolution \
    --parent-folder-path Shared
done

set -euo pipefailでは、エラーが発生すると、失敗したテナントでループが中止されます。後のテナントは影響を受けず、部分的な昇格は再実行または明示的にロールバックできます。

次のステップ

• 方法: CI から Orchestrator にデプロイ する — 認証、キャッシュ、ツールのプレインストールに関する、プラットフォームに依存しない詳細。
• CI/CD レシピ — Azure DevOps、GitHub Actions、Jenkins、GitLab 用のコピー/貼り付け可能なパイプライン。
• uip solution参照 — すべてのサブコマンド。
• スクリプティング パターン — 終了コードの分岐、べき等パイプライン、認証リトライ。