Comment procéder: compresser et publier une solution

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.

uip solution publish et toutes les sous-commandes uip solution deploy * acceptent --tenant <tenant-name> (court: -t) pour remplacer le locataire sélectionné par la session active. Pour une tâche de promotion CI:

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

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

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"

É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: redéployer la version précédente

Si le mauvais déploiement est en ligne, installez la version précédente au lieu de désinstaller d’abord. Le nom du déploiement reste le même; seulement --package-version modifications:

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

C’est le cas le plus courant. Orchestrator réactive le nouveau déploiement pour la clé de configuration et laisse les ressources du dossier intactes.

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:

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

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

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

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

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.