Comment procéder: compresser et publier une solution

Créez et publiez une solution UiPath dans des environnements de développement, d’étape et de production avec l’épinglage des versions et des directives de restauration.

Cette page reprend l'endroit où votre premier pipeline s'arrête. Il suppose que vous disposez déjà du flux à trois commandes travaillant sur un seul locataire et que vous souhaitez désormais transférer la même solution entre le développement → l'étape → la production, épingler les versions à des fins de reproductibilité et savoir exactement comment annuler une version incorrecte.

Si vous n'avez pas encore compressé une solution de bout en bout, lisez d'abord votre premier pipeline - tout ici s'appuie sur uip solution pack / publish / deploy run.

Ce que ce guide couvre

• Une dissociation de version qui s’exécute bien avec le flux Orchestrator.
• Promouvoir le même package via plusieurs locataires sans procéder à un compressage.
• Épingler la CLI et ses outils pour que chaque build soit reproductible.
• Restauration d'une version défectueuse avec uip solution packages delete et uip solution deploy uninstall.

Choisir une version, puis la bloquez

uip solution pack --version contrôle à la fois le nom de fichier .zip et le packageVersion utilisé par chaque étape en aval. La valeur par défaut est 1.0.0; un pipeline réel doit le transmettre explicitement.

Le contrôle de version sémantique (MAJOR.MINOR.PATCH) est le meilleur schéma pour le flux Orchestrator. Deux règles concrètes font la différence entre un historique propre et un historique non triable:

1. Ne réutilisez jamais une version. uip solution publish rejette une paire name+version qui existe déjà dans le flux. Traitez une publication rejetée comme un bogue de build, et non comme quelque chose à « corriger» en réexécutant pack
2. Utilisez les métadonnées de build, et non les horodatages dans le noyau de la version. Préférez 1.2.0-rc.3 à 1.2.0.20260424. Les premiers sont triés correctement dans le flux; ce dernier est techniquement valide, mais plus difficile à lire en un coup d'œil.

Une configuration CI type:

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

Le chemin d'accès .zip est déterministe (<outputDir>/<name>_<version>.zip) — voir uip solution pack — afin que les scripts puissent le calculer sans analyser JSON.

Promouvoir un package entre les locataires

Créez le package et publiez une fois par version, puis déployez à nouveau le même artefact dans chaque locataire. Le packaging à nouveau compressé par environnement risque de dériver; la republication de la même version est également idempotente par (name, version), donc si vous publiez deux fois par erreur, rien ne s’interrompt. Même ainsi, une construction = une publication est le contrat le plus propre.

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

Deux remarques:

• publish est idempotent par locataire. La publication du même (name, version) deux fois renvoie le PackageVersionKey existant au lieu de le dupliquer - voir uip solution publish.
• Les noms de déploiement doivent être à l'échelle du locataire. L'utilisation my-solution-prod au lieu de my-solution rend uip solution deploy list lisible et empêche les appels accidentels de deploy uninstall dans différents environnements. --name identifie l'enregistrement de déploiement, et non le dossier.

Paramétrage de la configuration par environnement

Si votre solution comporte des ressources (files d'attente, ressources) qui diffèrent par locataire, générez le fichier de configuration une fois et modifiez-le par environnement avec 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

Transmettez une ressource Orchestrator existante au lieu d'une ressource nouvellement créée avec deploy config link:

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

Mettre à niveau un déploiement vers une nouvelle version

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.

Épingler la CLI et ses outils

Les pipelines reproductibles épinglent chaque outil dont ils dépendent. La CLI est distribuée sur npm en tant que @uipath/cli; uip solution … est fourni par @uipath/solution-tool. Les deux suivent serveur.

# 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

Les versions de l’outil suivent par défaut la ligne MAJOR.MINIOR de la CLI: il suffit donc généralement d’épingler la CLI seule. Pour une reproductibilité stricte par correctif, épinglez également l’outil:

uip tools install @uipath/solution-tool@1.0.2

Voir Modèles de script — épinglage des versions dans CI et Installation de la UiPath CLI — CI/CD pour l'article complet.

Restaurer (Rollback)

L'interruption de la production est rare; être restauré lorsque vous en avez besoin. Il existe deux niveaux de restauration: redéployer une version connue (accélère) et supprimer l'artefact défectueux (nettoyage).

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.

Nettoyer: désinstaller le déploiement

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

Cela supprime toutes les ressources enregistrées et le dossier Solution. Il s'agit d'une opération irréversible - confirmez le nom du déploiement avec deploy list avant de l'exécuter, en particulier dans une boucle sur les locataires.

Retirer l’artefact

Une fois que rien ne fait référence à une mauvaise version, supprimez-la du flux du locataire avec uip solution packages delete:

uip login tenant set prod

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

Il n'y a pas de suppression réversible; ceci est permanent. Conservez la suppression dans une petite fenêtre - la commande accepte exactement un packageVersion à la fois, de sorte que les nettoyages en bloc de scripts nécessitent un modèle list → filter → xargs . Consultez la référence packages delete pour obtenir un exemple complet.

Vérifier ce que vous avez

Avant tout ce qui précède, obtenez la vérité du terrain:

# 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

Extrait prêt pour CI

Combinaison des étapes — un script shell que n'importe quel système CI peut exécuter tel quel:

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

Avec set -euo pipefail, tout échec abandonne la boucle au locataire défaillant. Les locataires ultérieurs ne sont pas affectés - la promotion partielle peut ensuite être réexécutée ou annulée explicitement.

Prochaines étapes

• Procédures: déployer dans Orchestrator à partir de CI — analyse approfondie indépendante de la plate-forme sur l'authentification, la mise en cache et la préinstallation de l'outil.
• Icônes CI/CD — pipelines copier-coller pour Azure DevOps, GitHub Actions, Jenkins, GitLab.
• uip solution référence — chaque sous-commande.
• Modèles de script — branchement-code-exit, pipelines idempotents, réessai d'authentification.