Ciclo de vida del desarrollo

Sigue una automatización de UiPath desde la máquina de un desarrollador hasta la producción cuando el código vive en un repositorio Git de terceros, con los comandos CLI que el proceso de versión se ejecuta en cada etapa.

Esta página sigue una automatización de UiPath desde la máquina de un desarrollador hasta la producción cuando el código, el historial y la colaboración se encuentran en un repositorio Git de terceros. Cada paso a continuación coincide con una operación numerada en el diagrama. Cada paso explica lo que sucede y, donde corresponde, muestra el uip que lo realiza. Los marcadores de posición en $CAPS son valores que proporcionas.

El camino feliz desde la máquina del desarrollador hasta la producción. Las barreras se ejecutan en la solicitud de extracción, por lo que main se mueve solo en una fusión que ya las haya superado, y esa fusión desencadena el proceso de versión. Los cuadros azules son sistemas que no son de UiPath, los cuadros naranjas son UiPath y los cuadros grises son entornos de runtime. Las flechas discontinuas son eventos, no acciones realizadas por una persona. Seleccione el diagrama para abrirlo en tamaño completo.

Requisitos previos

• Un repositorio de control de origen para tus proyectos de automatización.
• Un sistema de integración y entrega continuas (CI/CD) que puede ejecutar la CLI de UiPath y pausar para su aprobación manual.
• Separa los entornos de UiPath para el desarrollo, las pruebas y la producción.
• Credenciales que el proceso puede utilizar para autenticarse en UiPath. Consulta Autenticación.

Paso a paso

01. Guardar localmente

Studio escribe el proyecto en el disco del desarrollador. El trabajo está en curso y no es visible para nadie más.

No hay comando uip . Esta es una acción de Studio.

02. Depuración en desarrollo

El desarrollador ejecuta y depura el proyecto en el tenant de Desarrollo de Studio.

No hay comando uip . El desarrollador trabaja en Studio.

03. Insertar rama, abrir solicitud de extracción

El cambio sube en una rama de características y el desarrollador abre una solicitud de extracción en main.

No hay comando uip . Esta es una operación Git.

04. Validación de desencadenadores de solicitud de extracción

Al abrir la solicitud de extracción se activa el sistema CI automáticamente. Nadie inicia la ejecución a mano.

No hay comando uip . Este es un evento en el repositorio Git.

05. Obtener el código

La ejecución de validación comprueba el encabezado de la solicitud de extracción.

No hay comando uip . El sistema CI comprueba el código.

06. Análisis estático y otras barreras

El Analizador de flujo de trabajo y las reglas de control se ejecutan en el proyecto. Una infracción falla la ejecución antes de que main cambie. Para una solución, ejecuta el analizador una vez para cada proyecto que contenga.

uip rpa analyze ./my-solution/MyProject \
  --governance-file-path ./governance.json

Consulta uip rpa analizar.

07. Comprobaciones informadas en la solicitud de extracción

El resultado aparece como una comprobación de estado en la solicitud de extracción. La protección de ramas hace que la comprobación sea de bloqueo en lugar de de asesoramiento.

No hay comando uip . El sistema CI informa del resultado al repositorio Git.

08. Fusionar aprobación de PR

Un revisor aprueba, se aprueban las comprobaciones y la solicitud de extracción se fusiona en main.

No hay comando uip . Esta es una operación Git.

09. Enviar a principal desencadena el proceso

La confirmación de fusión en main desencadena el proceso de lanzamiento automáticamente.

No hay comando uip . Este es un evento en el repositorio Git.

10. Obtén el código

La ejecución de lanzamiento comprueba main en la confirmación de fusión.

No hay comando uip . El sistema CI comprueba el código.

11. Implementar en el entorno de pruebas/pruebas de aceptación del usuario (UAT)

El proceso de versión empaqueta la solución, la publica en el tenant de Pruebas/UAT y la implementa allí. El empaquetado se produce en este paso, porque la secuencia no tiene un paso de compilación independiente. Antes de la implementación, el proceso edita la configuración de implementación para que la solución reutilice los recursos que ya existen en el tenant en lugar de crear duplicados.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"

uip solution pack ./my-solution ./dist \
  --name my-solution --version "$BUILD_VERSION"

uip solution publish "./dist/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.uat.json
uip solution deploy config link ./deploy-config.uat.json "MyConnection" \
  --name "UatCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.uat.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-uat-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.uat.json

Para obtener más información sobre la vinculación de recursos declarados a los existentes, consulta Reutilizar recursos existentes de Orchestrator.

12. Ejecutar pruebas

El proceso ejecuta el conjunto de pruebas en la solución implementada en Staging/UAT, espera a que finalice la ejecución y obtiene el informe. Consulta Ejecutar pruebas en un proceso.

uip tm testsets run --test-set-key "$TEST_SET_KEY"
uip tm wait --execution-id "$EXECUTION_ID"
uip tm report get --execution-id "$EXECUTION_ID"

13. Notificar para validación

El proceso le dice al usuario empresarial que la versión está lista para la validación en Staging/UAT.

No hay comando uip . La puerta de aprobación en el sistema CI notifica a sus revisores por sí misma.

14. Validación empresarial

El usuario empresarial prueba la solución en el tenant de Staging/UAT. Mientras tanto, la ejecución del proceso se detiene en la puerta de aprobación y no sondea una respuesta.

No hay comando uip . Este es un paso humano.

15. Aprobación del usuario empresarial

El usuario empresarial aprueba la versión, lo que permite que el proceso continúe.

No hay comando uip . El aprobador actúa en el sistema CI, no en el shell.

16. Descargar paquete

El tenant de UAT también sirve como fuente de artefactos. Tome el paquete exacto que pasó las pruebas en lugar de empaquetarlo de nuevo desde el origen.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"
uip solution packages download my-solution "$BUILD_VERSION" -d ./artifacts/

17. Implementar en producción

El proceso publica el paquete en el tenant de producción y lo implementa, utilizando el mismo enfoque de configuración de implementación que el paso 11. Publica el mismo archivo que descargaste en el paso 16. No empaques por segunda vez.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$PROD_TENANT"

uip solution publish "./artifacts/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.prod.json
uip solution deploy config link ./deploy-config.prod.json "MyConnection" \
  --name "ProdCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.prod.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-prod-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.prod.json

Para obtener más información sobre la vinculación de recursos declarados a los existentes, consulta Reutilizar recursos existentes de Orchestrator.

Para revertir, ejecuta el mismo comando deploy run con --package-version "$PREVIOUS_VERSION".

Ver también

• Empaquetar y publicar una solución
• Ejecutar pruebas en un proceso
• Implementar en Orchestrator desde CI
• Recetas de CI/CD