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

根据版本固定和回滚指南，在开发、阶段和生产环境中打包并发布 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)重新发布相同版本也具有幂等性，因此，如果您错误地发布两次，也不会中断。即便如此，一次构建=一次发布是最简洁的合同。

对于 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

两个注意事项：

• 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始终在新文件夹中创建新部署，使用相同的--name再次运行不会就地更新现有部署；它将失败（除非您传递-y, --yes ，这将与第一个副本一起安装第二个独立副本）。要将实时部署就地迁移到较新的包版本，请改用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

目前仅支持将最新发布的版本作为升级目标。传递 --no-wait，在接受升级后立即返回，而不是等待升级完成。该机制可以反向应用，以撤消错误的版本 — 请参阅回滚。

固定 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 。

回滚

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

快速：将部署移回先前版本

如果错误部署处于活动状态，请先将其移回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

无法软删除；这是永久性的。将删除操作保持在一个小窗口内 — 该命令一次仅接受一个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引用— 每个子命令。
• 脚本模式— 退出代码分支、幂等管道、身份验证重试。