Tutorial: empaquetar y publicar una solución

Empaque y publique una solución de UiPath en entornos de desarrollo, etapa y producción con orientación de fijación de versiones y reversió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.

Para un trabajo de promoción de CI, cambia el tenant de la sesión activa entre iteraciones con uip login tenant set <tenant> y luego ejecuta publish/deploy run en cualquier tenant al que esté vinculada la sesión actualmente:

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

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

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"

Actualizar una implementación a una nueva versión

deploy run siempre crea una nueva implementación en una nueva carpeta: ejecutarla de nuevo con la misma --name no actualiza la implementación existente en su lugar; falla (a menos que pases -y, --yes, que instala una segunda copia independiente junto con la primera). Para mover una implementación en vivo a una versión de paquete más reciente, utiliza uip solution deploy upgrade en su lugar. Conserva la carpeta de la implementación, los recursos aprovisionados y cualquier configuración ya establecida en ellos (por ejemplo, el secreto de un activo de credenciales).

Primero busca la clave de la implementación con deploy list:

uip login tenant set prod

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

A continuación, actualízalo:

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

Actualmente, solo se admite la última versión publicada como destino de actualización. Transfiera --no-wait para volver tan pronto como se acepte la actualización en lugar de esperar a que finalice. La misma mecánica funciona a la inversa para deshacer una versión incorrecta: consulta Reversión.

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: mueve la implementación a la versión anterior

Si la mala implementación está activa, vuelve a moverla a la última versión buena conocida con deploy upgrade en lugar de desinstalar primero. Ten en cuenta que deploy upgrade solo admite la última versión publicada como destino hoy, por lo que esta ruta asume que la versión anterior es (o se ha vuelto a publicar como) el más reciente de la fuente:

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

Este es el caso común. Deja intactos los recursos aprovisionados de la carpeta y reutiliza la configuración existente.

Limpiar: desinstala la implementación

Si la solución aprovisionó recursos (colas, activos, desencadenadores) que no deseas, llama a uip solution deploy uninstall ; requiere -y, --yes ya que es irreversible:

uip login tenant set prod

uip solution deploy uninstall my-solution-prod --yes

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 login tenant set prod

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

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

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

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.