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.

Pour une tâche de promotion CI, basculez le locataire de la session active entre les itérations avec uip login tenant set <tenant>, puis exécutez publish/deploy run sur le locataire auquel la session est actuellement liée:

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 crée toujours un nouveau déploiement dans un nouveau dossier - l'exécuter à nouveau avec le même --name ne met pas à jour le déploiement existant en place; cela échoue (à moins que vous ne réussissiez -y, --yes, qui installe une deuxième copie indépendante à côté de la première). Pour déplacer un déploiement en direct vers une version de package plus récente en place, utilisez uip solution deploy upgrade à la place. Il préserve le dossier du déploiement, les ressources enregistrées et toute configuration déjà définie sur ces derniers (par exemple, le secret d’une ressource d’informations d’identification).

Recherchez d'abord la clé du déploiement avec deploy list:

uip login tenant set prod

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

Ensuite, mettez-le à niveau:

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

Seule la dernière version publiée est prise en charge comme cible de la mise à niveau aujourd'hui. Transmettez --no-wait pour renvoyer dès que la mise à niveau est acceptée au lieu d’attendre qu’elle se termine. Le même mécanisme fonctionne à l'inverse pour annuler une version incorrecte - voir Restauration.

É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).

Rapide: déplacez le déploiement à la version précédente

Si le mauvais déploiement est en ligne, déplacez-le vers la dernière version connue avec deploy upgrade au lieu de désinstaller d'abord - notez que deploy upgrade ne prend en charge que la dernière version publiée en tant que cible aujourd'hui, de sorte que ce chemin suppose que la version précédente est (ou a été republiée en tant que) la plus récente dans le flux:

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

C’est le cas le plus courant. Il laisse les ressources enregistrées du dossier intactes et réutilise la configuration existante.

Nettoyer: désinstaller le déploiement

Si la solution a enregistré des ressources (files d'attente, ressources, déclencheurs) dont vous ne voulez pas, appelez uip solution deploy uninstall — cela nécessite -y, --yes car il est irréversible:

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.