So: Packen und Veröffentlichen einer Lösung

Verpacken und Veröffentlichen einer UiPath-Lösung über Entwicklungs-, Phasen- und Produktumgebungen hinweg mit Version zum Anheften und Rollback.

Diese Seite setzt dort weiter, wo Ihre erste Pipeline aufhört. Es wird davon ausgegangen, dass Sie den Drei-Befehls-Flow bereits auf einem einzelnen Mandanten haben und jetzt dieselbe Lösung über Dev → Phase → Prod versenden möchten, Versionen für Reproduzierbarkeit anheften und genau wissen, wie Sie eine falsche Version zurücksetzen können.

Wenn Sie noch keine End-to-End-Lösung gepackt haben, lesen Sie zuerst Ihre erste Pipeline – hier basiert alles auf uip solution pack / publish / deploy run.

Was dieser Leitfaden behandelt

• Eine Versionierungsregeln , die gut zum Orchestrator-Feed passt.
• Fördern desselben Pakets über mehrere Mandanten ohne Neupack.
• Anheften der CLI und ihrer Tools, sodass jeder Build reproduziert werden kann.
• Rollback eines fehlerhaften Release mit uip solution packages delete und uip solution deploy uninstall.

Wählen Sie eine Version aus und sichern Sie sie dann

uip solution pack --version steuert sowohl den .zip Dateinamen als auch den packageVersion , den jeder nachgelagerte Schritt verbraucht. Der Standardwert ist 1.0.0; Eine echte Pipeline sollte sie explizit übergeben.

Die semantische Versionierung (MAJOR.MINOR.PATCH) ist das Schema, das der Orchestrator-Feed am besten sortiert. Zwei konkrete Regeln machen den Unterschied zwischen einem sauberen und einem nicht sortierbaren Verlauf:

1. Verwenden Sie eine Version niemals wieder. uip solution publish weist ein name+version -Paar zurück, das bereits im Feed vorhanden ist. Behandeln Sie eine abgelehnte Veröffentlichung als Build-Fehler und nicht als etwas, das durch erneutes Ausführen von pack behoben werden muss.
2. Verwenden Sie Buildmetadaten und keine Zeitstempel im Versionscore. Bevorzugen Sie 1.2.0-rc.3 vor 1.2.0.20260424. Ersteres wird korrekt im Feed sortiert; Letzteres ist technisch gültig, aber auf einen Blick schwieriger zu lesen.

Eine typische CI-Konfiguration:

# 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"

Der .zip -Pfad ist deterministisch (<outputDir>/<name>_<version>.zip) – siehe uip solution pack – sodass Skripte ihn berechnen können, ohne JSON zu analysieren.

Fördern Sie ein Paket für alle Mandanten

Packen und veröffentlichen Sie einmal pro Version und stellen Sie dann erneut dasselbe Artefakt in jedem Mandanten bereit. Das Neupacken pro Umgebung gefährdet die beschriebene Umgebung; Die erneute Veröffentlichung derselben Version ist auch idempotent gemäß (name, version). Wenn Sie also versehentlich zweimal veröffentlichen, funktioniert nichts. Trotzdem ist ein Build = eine Veröffentlichung der sauberste Vertrag.

Wechseln Sie für einen CI-Bereitstellungsauftrag den Mandanten der aktiven Sitzung zwischen den Iterationen mit uip login tenant set <tenant> und führen Sie dann publish/deploy run für den Mandanten aus, an den die Sitzung derzeit gebunden ist:

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

Zwei Hinweise:

• publish ist pro Mandant idempotent. Veröffentlichen von demselben (name, version) zweimal gibt die vorhandene PackageVersionKey zurück, anstatt sie zu duplizieren – siehe uip solution publish.
• Bereitstellungsnamen müssen einen Mandanten-Scope sein. Die Verwendung my-solution-prod anstelle von my-solution macht uip solution deploy list lesbar und verhindert versehentliche deploy uninstall -Aufrufe zwischen Umgebungen. --name identifiziert den Bereitstellungsdatensatz, nicht den Ordner.

Parametrisierung der Konfiguration pro Umgebung

Wenn Ihre Lösung über Ressourcen (Warteschlangen, Assets) verfügt, die sich je nach Mandant unterscheiden, generieren Sie die Konfigurationsdatei einmal und bearbeiten Sie sie pro Umgebung mit 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

Übergeben Sie eine vorhandene Orchestrator-Ressource anstelle einer neu erstellten mit deploy config link:

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

Upgraden Sie eine Bereitstellung auf eine neue Version

deploy run erstellt immer eine neue Bereitstellung in einem neuen Ordner – wenn Sie sie mit demselben --name erneut ausführen, wird die vorhandene Bereitstellung nicht aktualisiert; es schlägt fehl (es sei denn, Sie übergeben -y, --yes, wodurch eine zweite, unabhängige Kopie neben der ersten installiert wird). Um eine Live-Bereitstellung zu einer neueren Paketversion zu verschieben, verwenden Sie stattdessen uip solution deploy upgrade . Der Ordner der Bereitstellung, die bereitgestellten Ressourcen und alle bereits festgelegten Konfigurationen (z. B. das Geheimnis eines Anmeldeinformations-Assets) werden beibehalten.

Suchen Sie zuerst den Schlüssel der Bereitstellung mit deploy list:

uip login tenant set prod

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

Dann aktualisieren Sie ihn:

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

Nur die zuletzt veröffentlichte Version wird heute als Upgradeziel unterstützt. Übergeben Sie --no-wait, um zurückzukehren, sobald das Upgrade akzeptiert wurde, anstatt auf dessen Abschluss zu warten. Dieselbe Mechanismus funktioniert umgekehrt, um eine falsche Version rückgängig zu machen – siehe Rollback.

Heften Sie die CLI und die zugehörigen Tools an

Reproduzierbare Pipelines heften jedes Tool an, von dem sie abhängen. Die CLI wird auf npm als @uipath/cli verteilt; uip solution … wird von @uipath/solution-tool bereitgestellt. Beide folgen Sever.

# 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

Toolversionen verfolgen standardmäßig die MaJOR.MINOR-Zeile der CLI, sodass es in der Regel ausreicht, die CLI nur anzuheften. Für eine strikte Reproduzierbarkeit pro Patch heften Sie das Tool auch an:

uip tools install @uipath/solution-tool@1.0.2

Die vollständige Beschreibung finden Sie unter Skriptmuster – Anheften von Versionen in CI und Installieren von UiPath CLI – CI/CD .

Rollback

Produktionsunterbrechungen sind selten; zurücksetzen, wenn Sie wichtig sind. Es gibt zwei Rollback-Ebenen – eine erneute Bereitstellung einer bekannterstanding-Version (Schnell) und Löschen des fehlerhaften Artefakts (fehlerfrei).

Schnell: Verschieben Sie die Bereitstellung zurück zur vorherigen Version

Wenn die falsche Bereitstellung live ist, verschieben Sie sie mit deploy upgrade auf die letzte bekannter gute Version zurück, anstatt zuerst zu deinstallieren – beachten Sie, dass deploy upgrade nur die neueste veröffentlichte Version heute als Ziel unterstützt, sodass dieser Pfad davon ausgeht, dass die vorherige Version vorhanden ist (oder wurde neu veröffentlicht als) die neueste im 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

Das ist der häufigste Fall. Die bereitgestellten Ressourcen des Ordners bleiben erhalten und verwenden die vorhandene Konfiguration wieder.

Sauber: Deinstallieren Sie die Bereitstellung

Wenn die Lösung Ressourcen (Warteschlangen, Assets, Trigger) bereitgestellt hat, die Sie nicht möchten, rufen Sie uip solution deploy uninstall auf – es erfordert -y, --yes , da es nicht rückgängig gemacht werden kann:

uip login tenant set prod

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

Dadurch werden alle bereitgestellten Ressourcen und der Lösungsordner entfernt. Es handelt sich um einen unwiderruflichen Vorgang – bestätigen Sie den Bereitstellungsnamen mit deploy list , bevor Sie ihn ausführen, insbesondere in einer Schleife über Mandanten.

Ziehen Sie das Artefakt zurück

Sobald nichts auf eine falsche Version verweist, entfernen Sie sie mit uip solution packages delete aus dem Mandantenfeed:

uip login tenant set prod

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

Es gibt kein vorläufiges Löschen; Dies ist endgültig. Halten Sie die Löschung auf ein kleines Fenster – der Befehl akzeptiert genau ein packageVersion gleichzeitig, sodass das Skript für Massenbereinigung ein list → filter → xargs Muster erfordert. Ein vollständiges Beispiel finden Sie in der packages delete -Referenz.

Überprüfen, was Sie haben

Rufen Sie vor einer der oben genannten Aktionen die Ground Truth ab:

# 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-fähiges Snippet

Kombinieren der Schritte – ein Shell-Skript, das jedes CI-System so ausführen kann, wie es ist:

#!/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

Bei set -euo pipefail bricht jeder Fehler die Schleife beim fehlgeschlagenen Mandanten ab. Spätere Mandanten sind nicht betroffen – die teilweise Aktion kann dann erneut ausgeführt oder explizit zurückgesetzt werden.

Nächste Schritte

• Anleitung: Bereitstellen von CI im Orchestrator – plattformagnostische, detaillierte Einblicke in Authentifizierung, Zwischenspeicherung und Vorinstallation von Tools.
• CI/CD-Rezepte – kopieren und einfügen für Azure DevOps, GitHub Actions, Jenkins, GitLab.
• uip solution Referenz – jeder Unterbefehl.
• Skriptingmuster – Exit-Code-Verzweigung, idempotente Pipelines, Authentifizierungswiederholung.