Tutorial: empaquetar y publicar una solución

Esta página comienza donde se detiene tu primer proceso . Se supone que ya tienes el flujo de tres comandos funcionando en un solo tenant y ahora quieres enviar la misma solución a través de dev → etapa → producción, fijar versiones para la reproducibilidad y saber exactamente cómo revertir una mala versión.

Si aún no has empaquetado una solución de extremo a extremo, lee Tu primer proceso primero: todo aquí se basa en uip solution pack / publish / deploy run.

Qué cubre esta guía

• Una disciplina de control de versiones que funciona bien con la fuente de Orchestrator.
• Promocionar el mismo paquete a través de varios tenants sin volver a empaquetar.
• Fijar la CLI y sus herramientas para que cada compilación sea reproducible.
• Revirtiendo una versión rota con uip solution packages delete y uip solution deploy uninstall.

Elija una versión y congélela

uip solution pack --version controla tanto el nombre de archivo .zip como el packageVersion que consume cada paso posterior. El valor predeterminado es 1.0.0; un proceso real debe pasarlo explícitamente.

El control de versiones semántico (MAJOR.MINOR.PATCH) es el esquema que mejor ordena la fuente de Orchestrator. Dos reglas concretas marcan la diferencia entre un historial limpio y uno no clasificable:

1. Nunca reutilices una versión. uip solution publish rechaza un par name+version que ya existe en la fuente. Trata una publicación rechazada como un error de compilación, no como algo que "arreglar" volviendo a ejecutar pack.
2. Utiliza metadatos de compilación, no marcas de tiempo en el núcleo de la versión. Prefiere 1.2.0-rc.3 a 1.2.0.20260424. El primero se ordena correctamente en la fuente; este último es técnicamente válido semver pero más difícil de leer de un vistazo.

Una configuración de CI típica:

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

La ruta .zip es determinista (<outputDir>/<name>.<version>.zip) — consulta uip solution pack — por lo que los scripts pueden calcularla sin analizar JSON.

Promocionar un paquete entre tenants

Empaqueta y publica una vez por versión y luego vuelve a implementar el mismo artefacto en cada tenant. Reempaquetar por entorno corre el riesgo de deriva; volver a publicar la misma versión también es idempotente por (name, version), por lo que si publicas dos veces por error, nada se rompe. Aun así, una compilación = una publicación es el contrato más limpio.

uip solution publish y cada subcomando uip solution deploy * acepta --tenant <tenant-name> (abreviatura: -t) para anular el tenant seleccionado por la sesión activa. Para un trabajo de promoción de 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

Dos notas:

• publish es idempotente por tenant. Publicar el mismo (name, version) dos veces devuelve el PackageVersionKey existente en lugar de duplicarlo — consulta uip solution publish.
• Los nombres de implementación deben tener ámbito de tenant. El uso de my-solution-prod en lugar de my-solution hace que uip solution deploy list sea legible y evita las llamadas deploy uninstall accidentales entre entornos. --name identifica el registro de implementación, no la carpeta.

Parametrizar la configuración por entorno

Si tu solución tiene recursos (colas, activos) que difieren por tenant, genera el archivo de configuración una vez y edítalo por entorno con 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

Pasa un recurso de Orchestrator existente en lugar de uno recién creado con deploy config link:

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

Anclar la CLI y sus herramientas

Los procesos reproducibles fijan cada herramienta de la que dependen. La CLI se distribuye en npm como @uipath/cli; uip solution … lo proporciona @uipath/solution-tool. Ambos siguen a Semver.

# 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

Las versiones de la herramienta realizan de forma predeterminada el seguimiento de la línea MAYOR.MENOR de la CLI, por lo que suele bastar con fijar la CLI. Para una reproducibilidad estricta por parche, fija también la herramienta:

uip tools install @uipath/solution-tool@1.0.2

Consulta Patrones de scripts: fijar versiones en CI e Instalar UiPath CLI: CI/CD para ver la historia completa.

Reversión

La interrupción de la producción es rara; revertir cuando lo haces importa. Hay dos niveles de reversión: volver a implementar una versión buena conocida (rápido) y eliminar el artefacto defectuoso (limpio).

Rápido: volver a implementar la versión anterior

Si la mala implementación está activa, instala la versión anterior sobre ella en lugar de desinstalar primero. El nombre de la implementación sigue siendo el mismo; solo --package-version cambia:

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

Este es el caso común. Orchestrator reactiva la nueva implementación para la clave de configuración y deja intactos los recursos de la carpeta.

Limpiar: desinstala la implementación

Si la solución aprovisionó recursos (colas, activos, desencadenadores) que no deseas, llama a uip solution deploy uninstall:

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

Esto elimina todos los recursos aprovisionados y la carpeta Solución. Es una operación destructiva: confirma el nombre de la implementación con deploy list antes de ejecutarlo, especialmente en un bucle sobre tenants.

Retirar el artefacto

Una vez que nada haga referencia a una versión incorrecta, elimínala de la fuente del tenant con uip solution packages delete:

uip solution packages delete my-solution 1.2.0-ci.456 --tenant prod

No hay eliminación suave; esto es permanente. Mantén la eliminación en una ventana pequeña: el comando acepta exactamente un packageVersion a la vez, por lo que la creación de scripts de limpieza masiva requiere un patrón list → filter → xargs . Consulta la referencia packages delete para ver un ejemplo completo.

Comprobar lo que tienes

Antes de cualquiera de las anteriores, obtén la verdad fundamental:

# 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

Fragmento CI-ready

Combinando los pasos: un script de shell que cualquier sistema CI puede ejecutar tal cual:

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

Con, set -euo pipefail fallo aborta el bucle en el tenant que falla. Los tenants posteriores no se ven afectados: la promoción parcial puede volver a ejecutarse o revertirse explícitamente.

Próximos pasos

• Tutorial: implementar en Orchestrator desde CI : profundización independiente de la plataforma en autenticación, almacenamiento en caché y preinstalación de herramientas.
• Recetas de CI/CD : procesos copiables para Azure DevOps, GitHub Actions, Jenkins, GitLab.
• Referenciauip solution : cada subcomando.
• Patrones de scripting : ramificación de código de salida, procesos idempotentes, reintento de autenticación.