Cycle de vie de développement

Suivez une automatisation UiPath depuis la machine d'un développeur jusqu'à la production lorsque le code réside dans un référentiel Git tiers, avec les commandes CLI pour que le pipeline de version s'exécute à chaque étape.

Cette page suit une automatisation UiPath depuis la machine d'un développeur jusqu'à la production lors du code, de l'historique et de la collaboration en direct dans un référentiel Git tiers. Chaque étape ci-dessous correspond à une opération numérotée dans le diagramme. Chaque étape explique ce qui se passe et, lorsqu'une étape s'applique, affiche la commande uip qui l'effectue. Les espaces réservés dans $CAPS sont des valeurs que vous fournissez.

Le chemin heureux entre la machine du développeur et la production. Les garde-fous s'exécutent sur la demande pull, de sorte que le déplacement principal se déplace uniquement sur une fusion qui les a déjà dépassées, et cette fusion déclenche le pipeline de version. Les boîtes bleues sont des systèmes qui ne sont pas basés sur UiPath, les boîtes oranges sont des systèmes UiPath et les boîtes grises sont des environnements de runtime. Les flèches en pointillés sont des événements, et non des actions entreprises par une personne. Sélectionnez le diagramme pour l'ouvrir en taille réelle.

Prérequis

• Un référentiel de contrôle de code source pour vos projets d'automatisation.
• Un système d'intégration continue et de livraison continue qui peut exécuter la UiPath CLI et suspendre l'approbation manuelle.
• Séparez les environnements UiPath du développement, des tests et de la production.
• Les informations d'identification que le pipeline peut utiliser pour s'authentifier auprès d'UiPath. Voir Authentification.

Étape par étape

01. Enregistrer localement

Studio écrit le projet sur le disque du développeur. Le travail est en cours et n’est visible par aucun autre utilisateur.

Aucune commande uip . Il s'agit d'une action Studio.

02. Déboguer le développement

Le développeur exécute et débogue le projet par rapport au locataire de développement de Studio.

Aucune commande uip . Le développeur travaille dans Studio.

03. Transmettre la branche, ouvrir la demande pull

La modification va sur une branche de fonctionnalité, et le développeur ouvre une demande pull à l'encontre de main.

Aucune commande uip . Il s'agit d'une opération Git.

04. Validation des déclencheurs de demande pull

L'ouverture de la demande pull déclenche automatiquement le système CI. Aucun ne démarre l'exécution par la main.

Aucune commande uip . Il s'agit d'un événement dans le référentiel Git.

05. Obtenir le code

L'exécution de la validation vérifie la chaîne de la demande pull.

Aucune commande uip . Le système CI extrait le code.

06. Analyse statique et autres garde-fous

L'analyseur de workflow et les règles de gouvernance s'exécutent dans le projet. Une violation échoue l’exécution avant que main ne soit modifié. Dans le cas d’une solution, exécutez l’analyseur une fois pour chaque projet qu’il contient.

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

Voir analyse uip rpa.

07. Vérifications signalées sur la demande pull

Le résultat apparaît sous la forme d’une vérification du statut de la demande pull. La protection de la branche rend le blocage de la vérification plutôt que le conseil.

Aucune commande uip . Le système CI indique le résultat dans le référentiel Git.

08. Fusionner le prérequis approuvé

Un réviseur approuve, les vérifications sont validées et la demande pull est fusionnée dans main

Aucune commande uip . Il s'agit d'une opération Git.

09. Transmettre vers le déclencheur principal déclenche le pipeline

La validation de fusion sur main déclenche automatiquement le pipeline de version.

Aucune commande uip . Il s'agit d'un événement dans le référentiel Git.

10. Obtenir le code

L’exécution de la version extrait main au moment de la validation de la fusion.

Aucune commande uip . Le système CI extrait le code.

11. Déployer vers l'environnement d'organisation/de test d'acceptation utilisateur

Le pipeline de version compresse la solution, la publie dans le locataire Staging/UAT et la déploie. Le processus de compression se produit lors de cette étape, car la séquence ne comporte aucune étape de création distincte. Avant le déploiement, le pipeline modifie la configuration du déploiement afin que la solution réutilise les ressources qui existent déjà dans le locataire au lieu de créer des doublons.

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

Pour plus de détails sur la liaison des ressources déclarées à des ressources existantes, consultez Réutiliser les ressources Orchestrator existantes.

12. Exécuter des tests

Le pipeline exécute l'ensemble de tests par rapport à la solution déployée dans Organisation/UAT, attend la fin de l'exécution et obtient le rapport. Voir Exécuter les tests dans un pipeline.

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. Aviser pour validation

Le pipeline indique à l’utilisateur professionnel que la version est prête à être validée dans Staging/UAT.

Aucune commande uip . La passerelle d'approbation dans le système CI informe ses réviseurs de manière autonome.

14. Validation métier

L’utilisateur métier teste la solution dans le locataire Staging/UAT. Pendant ce temps, l'exécution du pipeline s'interrompt au niveau de la passerelle d'approbation et n'interroge pas de réponse.

Aucune commande uip . Il s'agit d'une étape humaine.

15. Approbation de l’utilisateur professionnel

L'utilisateur professionnel approuve la version, ce qui permet au pipeline de se poursuivre.

Aucune commande uip . L'approbateur agit dans le système CI, et non dans le shell.

16. Télécharger le package

Le locataire UAT sert également de flux d’artefacts. Prenez le package exact qui a réussi les tests au lieu de le compresser à nouveau depuis la source.

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. Déployer en production

Le pipeline publie le package sur le locataire de production et le déploie, en utilisant la même approche de configuration de déploiement qu'à l'étape 11. Publiez le même fichier que vous avez téléchargé à l'étape 16. Ne compressez pas une seconde fois.

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

Pour plus de détails sur la liaison des ressources déclarées à des ressources existantes, consultez Réutiliser les ressources Orchestrator existantes.

Pour revenir en arrière, exécutez la même commande deploy run avec --package-version "$PREVIOUS_VERSION"

Voir également

• Créer et publier une solution
• Exécuter les tests dans un pipeline
• Déployer vers Orchestrator à partir du CI
• Revenus CI/CD