So: Packen und Veröffentlichen einer Lösung

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.

uip solution publish und jeder uip solution deploy * -Unterbefehl akzeptieren --tenant <tenant-name> (kurz: -t), um den von der aktiven Sitzung ausgewählten Mandanten zu überschreiben. Für einen Auftrag zur CI-Bereitstellung:

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

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

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

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: Stellen Sie die vorherige Version erneut bereit

Wenn die falsche Bereitstellung live ist, installieren Sie die vorherige Version darüber , anstatt sie zuerst zu deinstallieren. Der Bereitstellungsname bleibt gleich; nur --package-version Änderungen:

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

Das ist der häufigste Fall. Der Orchestrator aktiviert die neue Bereitstellung für den Konfigurationsschlüssel erneut und lässt die Ressourcen des Ordners unverändert.

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:

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

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 solution packages delete my-solution 1.2.0-ci.456 --tenant prod

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 --take 50 \
  --output-filter "Data[?packageName=='my-solution']"

# What is deployed?
uip solution deploy list --folder-path Shared --take 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 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

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.