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

このページでは、 最初のパイプライン が停止する場所を取り上げます。これは、既に 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 つのパブリッシュが最もクリーンなコントラクトです。

uip solution publish およびすべての uip solution deploy * サブコマンドは、 --tenant <tenant-name> (略称: -t)を受け入れて、アクティブなセッションによって選択されたテナントをオーバーライドします。CI 昇進ジョブの場合:

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

for tenant in dev stage prod; do
  uip solution publish "./dist/my-solution.${VERSION}.zip" --tenant "$tenant"

  uip solution deploy run \
    --name "my-solution-${tenant}" \
    --package-name my-solution \
    --package-version "$VERSION" \
    --folder-name MySolution \
    --folder-path Shared \
    --tenant "$tenant"
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 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 \
  --folder-path Shared \
  --config-file ./deploy-config.json \
  --tenant prod

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

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

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つのレベルがあります。

高速: 以前のバージョンを再デプロイする

不適切なデプロイが稼働中の場合は、最初にアンインストールするのではなく、以前のバージョンを その上に インストールします。デプロイ名は変更されません。 --package-version 変更のみ:

uip solution deploy run \
  --name my-solution-prod \
  --package-name my-solution \
  --package-version 1.1.9 \
  --folder-name MySolution \
  --folder-path Shared \
  --tenant prod

これは一般的なケースです。Orchestrator は、設定キーの新しいデプロイを再アクティブ化し、フォルダーのリソースはそのまま残ります。

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

ソリューションによって不要なリソース (キュー、アセット、トリガー) がプロビジョニングされた場合は、次のuip solution deploy uninstallを呼び出します。

uip solution deploy uninstall my-solution-prod --tenant prod

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

成果物を廃止する

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

uip solution packages delete my-solution 1.2.0-ci.456 --tenant prod

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

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

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

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

# What is deployed?
uip solution deploy list --folder-path Shared --take 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 solution publish "$PKG" --tenant "$tenant"
  uip solution deploy run \
    --name "my-solution-${env_name}" \
    --package-name my-solution \
    --package-version "$VERSION" \
    --folder-name MySolution \
    --folder-path Shared \
    --tenant "$tenant"
done

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

次のステップ

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