操作方法：打包并发布解决方案

根据版本固定和回滚指南，在开发、阶段和生产环境中打包并发布 UiPath 解决方案。

此页面将选取您的第一个管道停止的位置。它假设您已经在单个租户上运行了三命令流程，现在希望在开发 → 阶段 → 产品阶段交付相同的解决方案，固定版本以提高可重复性，并确切知道如何撤销错误的版本。

如果您尚未端到端打包解决方案，请先阅读您的第一个管道— 此处的一切内容均基于uip solution pack / publish / deploy run构建。

本指南的涵盖内容

• 与 Orchestrator 订阅源兼容的版本控制规则。
• 通过多个租户提升同一个包，无需重新打包。
• 固定CLI 及其工具，以便每个构建均可重现。
• 使用 和uip solution packages deleteuip solution deploy uninstall 回滚 损坏的版本。

选择一个版本，然后冻结

uip solution pack --version同时控制.zip文件名和每个下游步骤消耗的packageVersion 。默认值为1.0.0 ；真实的管道应显式传递它。

语义版本控制 ( MAJOR.MINOR.PATCH ) 是 Orchestrator 订阅源的最佳排序方案。两个具体规则决定了干净历史记录与不可排序的历史记录的区别：

1. 切勿重复使用版本。uip solution publish将拒绝订阅源中已存在的name+version对。将拒绝的发布视为构建错误，而不是通过重新运行pack来“修复”的问题。
2. 在版本核心中使用内部版本元数据，而非时间戳。相对于1.2.0-rc.3优先使用1.2.0.20260424 。前者在订阅源中正确排序；后者在技术上是有效的 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 即可计算它。

跨租户提升一个包

每个版本打包并发布一次，然后将相同的工件重新部署到每个租户中。按环境风险重新打包；根据(name, version)重新发布相同版本也具有幂等性，因此，如果您错误地发布两次，也不会中断。即便如此，一次构建=一次发布是最简洁的合同。

For a CI promotion job, switch the active session's tenant between iterations with uip login tenant set <tenant>, then run publish/deploy run against whichever tenant the session is currently bound to:

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

两个注意事项：

• publish对租户而言具有幂等性。发布相同的(name, version)两次将返回现有的PackageVersionKey ，而不是复制 — 请参阅uip solution publish 。
• 部署名称应在租户范围内。使用my-solution-prod而非my-solution可使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 资源，而不是新创建的资源：

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

将部署升级到新版本

deploy run always creates a new deployment in a new folder — running it again with the same --name does not update the existing deployment in place; it fails (unless you pass -y, --yes, which installs a second, independent copy alongside the first). To move a live deployment to a newer package version in place, use uip solution deploy upgrade instead. It preserves the deployment's folder, provisioned resources, and any configuration already set on them (for example a credential asset's secret).

First find the deployment's key with deploy list:

uip login tenant set prod

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

Then upgrade it:

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

Only the latest published version is supported as an upgrade target today. Pass --no-wait to return as soon as the upgrade is accepted instead of waiting for it to finish. The same mechanic works in reverse to undo a bad release — see Rollback.

固定 CLI 及其工具

可重现的管道会固定其所依赖的每个工具。CLI 在 npm 上作为@uipath/cli分发； uip solution …由@uipath/solution-tool提供。两者都遵循语义化版本。

# 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

有关完整信息，请参阅“脚本编写模式 — 在 CI 中固定版本”和安装 UiPath CLI — CI/CD 。

回滚

很少会出现中断生产的情况；在执行重要操作时回滚。回滚有两个级别 —重新部署已知良好的版本（快速）并删除损坏的工件（干净）。

Fast: move the deployment back to the previous version

If the bad deployment is live, move it back to the last known-good version with deploy upgrade instead of uninstalling first — note that deploy upgrade only supports the latest published version as a target today, so this path assumes the previous version is (or has been republished as) the newest one in the feed:

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

This is the common case. It leaves the folder's provisioned resources intact and reuses the existing configuration.

清理：卸载部署

If the Solution provisioned resources (queues, assets, triggers) that you do not want, call uip solution deploy uninstall — it requires -y, --yes since it is irreversible:

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

无法软删除；这是永久性的。将删除操作保持在一个小窗口内 — 该命令一次仅接受一个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 系统都可以按原样运行的 Shell 脚本：

#!/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引用— 每个子命令。
• 脚本模式— 退出代码分支、幂等管道、身份验证重试。