UiPath® Automation Ops™ - Pipelines

Automation Ops™ - Pipelines offre un moyen simple de configurer un système d'intégration/de livraison continue afin de gérer le code de vos projets d'automatisation dans des référentiels externes, tels que Github ou Azure DevOps.

Les pipelines contiennent un ensemble d'étapes qui reposent sur des processus d'automatisation utilisés pour modifier le code dans votre environnement. Ces processus, également appelés Processus de pipeline ), utilisent le package d'activités Pipeline . Pour qu'un utilisateur puisse vérifier ces processus de pipeline, il doit avoir accès au dossier Orchestrator qui les contient.

Lorsqu'un pipeline est déclenché, une tâche est démarrée qui exécute le processus de pipeline associé à l'aide d'un robot Unattended.

Prérequis

• Versions du robot :
  • 2021.10 et 2022.4 : .NET Desktop Runtime 6.0.* doit être installé manuellement sur la machine robot.
  • 2022.8 et versions ultérieures : .NET Desktop Runtime est automatiquement installé avec le robot.
• Particularités du processus :
  • Le processus de pipeline doit être configuré pour s'exécuter en tant que processus d'arrière-plan. Pour ce faire, rendez-vous dans le menu des paramètres du projet dans Studio. En savoir plus sur les processus d’arrière-plan.
  • Lors de la publication du processus de pipeline de Studio vers Orchestrator, assurez-vous également de sélectionner Inclure les sources dans la section Options de publication . En savoir plus sur la publication de projets d’automatisation.

Configuration

Automation Ops™ : les pipelines fonctionnent en exécutant des processus de pipeline à l'aide de robots Unattended, ce qui signifie qu'une configuration spécifique dans Orchestrator est nécessaire avant de les utiliser. Cette configuration est appelée un environnement du runtime de pipelines.

La configuration de base d'Orchestrator dispose d'un dossier dédié qui contient les processus de pipeline et un compte Robot, ainsi qu'une machine ou un modèle de machine pour exécuter les tâches du pipeline.

Important :

Le compte Robot créé lors de la configuration rapide est essentiel. Tous les pipelines (tâches Orchestrator) sont exécutés en son nom. La suppression du compte Robot entraîne une configuration de runtime de pipeline non valide et le besoin de réexécuter la configuration rapide. La suppression du dossier de pipelines dédié dans Orchestrator interrompt tous les pipelines qui lui sont associés.

Configuration initiale

Lors de la configuration d'Automation Ops™ - Pipelines pour la première fois, une fenêtre de configuration rapide s'affiche, vous permettant de choisir le Locataire (Tenant) et le type de machine avec lequel vous souhaitez exécuter les futurs pipelines. Vous pouvez choisir entre utiliser une machine existante à partir de votre environnement ou créer automatiquement une nouvelle machine sans serveur nommée « Robot Pipelines ».

Remarque :

Si vous choisissez de créer une nouvelle machine sans serveur, assurez-vous qu'il y a suffisamment de Robot Units disponibles sur votre locataire.

Dans le cadre de l'expérience de configuration rapide, un nouveau dossier nommé « Pipelines » et les rôles suivants sont automatiquement créés :

• Rôle du locataire des pipelines
• Rôle du dossier Pipelines

Le robot pipelines se voit attribuer automatiquement les rôles suivants :

• Locataire: rôle du locataire de pipelines, Autoriser à être un utilisateur d’automatisation, Autoriser à être Automation Publisher
• Dossier des pipelines: rôle du dossier des pipelines, Automation User, Automation Publisher

Remarque :

Assurez-vous que le compte Robot créé pour les pipelines est également affecté au dossier Orchestrator cible. Cela est nécessaire car les pipelines fonctionnent sous ce compte. Pour de plus amples informations, reportez-vous à la section Configurer les accès pour les comptes.

L'activité Exécuter les tests (Run Tests) exécute les tests dans le dossier Orchestrator fourni. Le compte Robot Pipelines publie le package dans le dossier respectif, mais les tests peuvent être exécutés par n'importe quel compte Robot de ce dossier qui se valide pour le test, et pas seulement par le compte Robot Pipelines.

De plus, les processus de pipelines prédéfinis sont disponibles par défaut, comme présenté dans le tableau suivant :

Build.and.publish	Cloner (Clone) -> Analyser (Analyze) -> Construire (Build) -> Publier (Publish)
Copy.package.between.environments	Télécharger le package (Download package) -> Publier le package (Publish package)
Update.process.from.code	Cloner (Clone) -> Analyser (Analyze) -> Créer (Build) -> Publier le package (Publish package) -> Mettre à jour le processus (Update process)
Update.with.tests	Cloner -> Analyser -> Exécuter les tests -> Créer -> Publier le package -> Mettre à jour le processus
Build.and.promote.with.approval	Cloner -> Analyser -> Exécuter les tests -> Créer -> Publier le package -> Mettre à jour le processus -> Approuver -> Télécharger le package -> Télécharger le package -> Mettre à jour le processus

Ces processus de pipelines par défaut sont fournis avec leur propre ensemble d'arguments, par exemple, le processus Build.and.promomote.with.approuverval a les arguments suivants :

• Ignorer les tests - Permet de choisir si les cas de test sont exécutés ou non pendant le pipeline.
• DossierTest : le dossier Orchestrator dans lequel les tests sont exécutés.
• AnalyserPolitique : la politique de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si ce champ est laissé vide, l’analyse du projet sera ignorée.
• IgnorerValidation : vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
• Approbateur : l’adresse e-mail de l’approbateur de la tâche créée dans Action Center.
• Première URL d’Orchestrator : l’URL d’Orchestrator où le package créé est publié.
• PremierDossierOrchestrator : le dossier Orchestrator dans lequel le package créé est publié.
• SecondOrchestratorUrl : l'URL d'Orchestrator où le package créé est publié après approbation.
• SecondOrchestratorFolder : le dossier Orchestrator dans lequel le package créé est publié après approbation.
• Avoir le même flux de paquets - Ce champ est défini sur «False» par défaut. Définissez-le sur « True » si les premier et deuxième environnements utilisent le même flux de package/bibliothèque.
• Nom du processus - Nom du processus à mettre à jour. Uniquement utilisé si le projet est un processus.

Vous pouvez également commencer à travailler avec les pipelines à l'aide des modèles disponibles dans Uipath Studio et Studio Web (onglet Modèles ).

Vous pouvez utiliser les modèles suivants :

• Build and promote with approval pipeline :

  • Utilisation : gestion d’un projet d’automatisation de sa création à son approbation.
  • Étapes : Cloner (Clone), Analyser (Analyze), Exécuter le test (Run Test), Créer (Build), Publier le package (Publish Package), Mettre à jour le processus (Update Process), Approuver (Approve), Télécharger le package (Download Package), Charger le package (Upload Package) et Mettre à jour le package (Update Package).

• Update process from a code line :

  • Utilisation : met en évidence une procédure simplifiée pour les mises à jour et les modifications des processus en cours.
  • Étapes : cloner, analyser, créer, publier le package et mettre à jour le processus.

Important :

Les robots Cloud Serverless créés dans la configuration initiale sont de taille standard . Lorsque vous utilisez l'activité RunTests, s'il s'agit d'un dossier Orchestrator avec des robots Cloud Serverless, assurez-vous que les robots sont de taille standard.

Lorsque vous utilisez l'activité Build, validez les exigences de compatibilité entre les projets d'automatisation que vous construisez et la machine qui exécute le processus.

Par exemple, un projet créé à l'aide de la compatibilitéWindows-Legacy or Windows ne peut pas être construit sur un robot Cloud Serverless. Vous devez utiliser une machine basée sur Windows à la place.

Lors de l'exécution d'un pipeline qui génère et publie un processus à l'aide des connexions Integration Service, assurez-vous que tous les dossiers de projet nécessaires sont validés par votre fournisseur de contrôle de code source. Par exemple, il est nécessaire lors de l'initialisation de Git à partir de Studio, de valider tous les dossiers de projet associés, tels que .settings, .project, .tmh.

Créer le premier pipeline

Une fois la configuration d'Orchestrator terminée, vous devez configurer l'intégration initiale entre les pipelines Automation Ops™, le référentiel GitHub contenant votre code et l'environnement de runtime des pipelines Orchestrator. Lors de cette intégration, vous créez également le premier pipeline.

Suivez ces étapes :

1. Dans Automation Cloud™, accédez à Automation Ops™ > Pipelines dans la barre de navigation de gauche.

2. Sélectionnez Nouveau pipeline. Si le référentiel externe est connecté au contrôle de code source, il est alors automatiquement connecté.

   Remarque :

   Une seule organisation UiPath® Automation Cloud™ peut être connectée en même temps à une organisation GitHub.

3. Dans l'onglet Emplacement , sélectionnez l'organisation du référentiel externe, le référentiel, la branche et un projet d'automatisation (facultatif). Sélectionnez Suivant.

   

4. Dans l'onglet Définition du pipeline , sélectionnez le processus de pipeline. Si votre processus de pipeline contient des arguments, vous pouvez ajouter leurs valeurs.
   

5. Dans l'onglet Enregistrer et exécuter , configurez les éléments suivants :

   • Nom du projet : saisissez un nom pour le projet de pipeline. Par défaut, le nom est composé du nom du référentiel et du nom du projet d'automatisation du pipeline.
   • Description : ajoutez éventuellement une description.
   • Exécuter ce pipeline : sélectionnez comment vous souhaitez que le pipeline s'exécute :
     • Pour chaque validation : l'automatisation du pipeline est déclenchée chaque fois que le code du référentiel comporte une modification pour le projet sélectionné.
     • Je l'exécuterai manuellement : l'automatisation du pipeline est déclenchée manuellement.
       Remarque :

       Sur les pipelines déclenchés manuellement, la validation utilisée lors du démarrage d'une tâche est la dernière validation du dossier du fichier project.json sélectionné. Il ne s'agit pas de la dernière validation du référentiel entier, si aucun fichier de ce dossier n'est modifié dans cette validation.

6. Sélectionnez Enregistrer pour enregistrer le pipeline ou Enregistrer et exécuter pour enregistrer et également exécuter le pipeline.

Important :

Si aucun processus spécifique du référentiel n'est choisi à l'étape 1 et que le pipeline est défini pour être déclenché par une validation, le pipeline est déclenché par n'importe quelle validation dans le référentiel.

L'argument ProjectPath est renseigné avec la valeur sélectionnée dans le champ Automation project (optional) de l' Étape d'emplacement de la configuration du pipeline. Si le champ est laissé vide, l’argument de processus ProjectPath reste vide. Ce scénario peut être utilisé pour les référentiels qui n'ont qu'un seul projet d'automatisation.

Exécution manuelle d'un pipeline

1. Dans Automation Cloud™, accédez à Automation Ops™ dans la barre de navigation de gauche.
2. Sélectionnez Pipelines. Les pipelines disponibles sont affichés.
3. Sélectionnez un pipeline, puis sélectionnez Démarrer une nouvelle tâche. Cela déclenche l'exécution du pipeline et vous pouvez suivre la progression de chaque étape en temps réel.

Vous pouvez également modifier le pipeline en sélectionnant Paramètres du pipeline. Cela affichera le résumé du pipeline, à partir duquel vous pourrez :

• Modifier le pipeline : sélectionnez cette option pour effectuer des mises à jour sur le pipeline. Vous pouvez uniquement mettre à jour le nom du pipeline, la description, le type de déclencheur et les arguments personnalisés du pipeline. L'emplacement et la définition du pipeline ne peuvent pas être modifiés.
• Supprimer le pipeline : sélectionnez cette option pour supprimer le pipeline (toutes les informations liées au pipeline seront supprimées).

Processus de pipeline prédéfinis

Le tableau suivant décrit les processus de pipelines prédéfinis disponibles par défaut :

Build.and.publish	Cloner (Clone) -> Analyser (Analyze) -> Construire (Build) -> Publier (Publish)
Copy.package.between.environments	Télécharger le package (Download package) -> Publier le package (Publish package)
Update.process.from.code	Cloner (Clone) -> Analyser (Analyze) -> Créer (Build) -> Publier le package (Publish package) -> Mettre à jour le processus (Update process)
Update.with.tests	Cloner -> Analyser -> Exécuter les tests -> Créer -> Publier le package -> Mettre à jour le processus
Build.and.promote.with.approval	Cloner -> Analyser -> Exécuter les tests -> Créer -> Publier le package -> Mettre à jour le processus -> Approuver -> Télécharger le package -> Télécharger le package -> Mettre à jour le processus

Les dernières versions des modèles de pipeline prédéfinis sont disponibles dans Marketplace.

Ces processus de pipelines par défaut sont fournis avec l'ensemble d'arguments suivant :

• Construire.et.promer.avec.processus.d'approbation :
  • Nom du processus - Nom du processus à mettre à jour. Uniquement utilisé si le projet est un processus.
  • Approbateur : l’adresse e-mail de l’approbateur de la tâche créée dans Action Center.
  • Ignorer les tests - Permet de choisir si les cas de test sont exécutés ou non pendant le pipeline.
  • AnalyserPolitique : la politique de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si ce champ est laissé vide, l’analyse du projet sera ignorée.
  • IgnorerValidation : vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • PremierDossierOrchestrator : le dossier Orchestrator dans lequel le package créé est publié.
  • Première URL d’Orchestrator : l’URL d’Orchestrator où le package créé est publié.
  • SecondOrchestratorFolder : le dossier Orchestrator dans lequel le package créé est publié après approbation.
  • SecondOrchestratorUrl : l'URL d'Orchestrator où le package créé est publié après approbation.
  • DossierTest : le dossier Orchestrator dans lequel les tests sont exécutés.
  • Avoir le même flux de paquets - Ce champ est défini sur «False» par défaut. Définissez-le sur « True » si les premier et deuxième environnements utilisent le même flux de package/bibliothèque.
• Build.and.publish
  • AnalyserPolitique : la politique de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si ce champ est laissé vide, l’analyse du projet sera ignorée.
  • IgnorerValidation : vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • URLOrchestrator : l’URL d’Orchestrator où le package créé est publié.
  • Dossier Orchestrator : le dossier Orchestrator dans lequel le package créé est publié.
• Copy.package.between.environments
  • Nom du package - Nom du package à copier.
  • Bibliothèque : définit si le package est une bibliothèque ou non.
  • Version du package - Version du package à copier.
  • SourceOrchestratorFolder : le dossier Orchestrator à partir duquel le package est copié.
  • URLSourceOrchestrator : l'URL de l'Orchestrator à partir duquel le package est copié.
  • URL d'Orchestrator de destination : l'URL d'Orchestrator vers lequel le package est copié.
  • DestinationOrchestratorFolder : le dossier Orchestrator vers lequel le package est copié.
• Update.process.from.code
  • Nom du processus - Nom du processus à mettre à jour. Uniquement utilisé si le projet est un processus.
  • AnalyserPolitique : la politique de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si ce champ est laissé vide, l’analyse du projet sera ignorée.
  • IgnorerValidation : vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • URLOrchestrator : l'URL d'Orchestrator où se trouve le package à mettre à jour.
  • Dossier Orchestrator - Dossier Orchestrator où se trouve le package à mettre à jour.
• Update.with.tests
  • Nom du processus - Nom du processus à mettre à jour. Uniquement utilisé si le projet est un processus.
  • AnalyserPolitique : la politique de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si ce champ est laissé vide, l’analyse du projet sera ignorée.
  • Ignorer les tests : permet d'ignorer les tests avant de créer le package. Cette valeur est désactivée par défaut.
  • URLOrchestrator : l'URL d'Orchestrator où se trouve le package à mettre à jour.
  • Dossier Orchestrator - Dossier Orchestrator où se trouve le package à mettre à jour.
  • OrchestratorTestingFolder : le dossier Orchestrator où se trouvent les tests utilisés dans le pipeline.

Remarque :

Il existe une exigence de compatibilité entre les projets d'automatisation que vous avez l'intention de créer et la machine qui exécute le processus de pipeline.

Le mappage correct est :

• Projet Windows hérité → Build OS : Windows uniquement
• Projet Windows (Windows project) → Build OS (Build OS) : Windows uniquement
• Projet multiplateforme→ Créer le système d'exploitation (Build OS) : Windows ou Linux

Arguments de processus de pipeline par défaut

Automation Ops™ fournit un ensemble d'arguments par défaut pour le processus de pipeline, présenté dans le tableau suivant :

Nom	Direction	Types d'arguments	Description
NuméroBuild	dans	Chaîne de caractères (string)	Un numéro unique pour chaque exécution de tâche de pipeline.
URL du référentiel	dans	Chaîne de caractères (string)	URL du référentiel. Généralement utilisé par l’activité Clone (Clone).
Hachage SHA de validation	dans	Chaîne de caractères (string)	Identificateur de validation.
Chemin d’accès au projet	dans	Chaîne de caractères (string)	Chemin d'accès au fichier project.json. Utile pour l’activité Build.
NomUtilisateurCommitter	dans	Chaîne de caractères (string)	Le nom d'utilisateur de la personne ayant déclenché la validation.
RepositoryType	dans	Chaîne de caractères (string)	Le type de référentiel (tel que git).
RepositoryBranch	dans	Chaîne de caractères (string)	La branche de référentiel utilisée.

Afficher les journaux du pipeline

Des journaux sont générés pour chaque exécution du pipeline. Vous pouvez afficher les journaux dans Automation Ops™ et, comme chaque exécution de pipeline crée une tâche dans Orchestrator, vous pouvez également les afficher dans Orchestrator :

• Dans Automation Ops™, pointez le côté droit d’un pipeline, puis, dans le menu contextuel, sélectionnez Afficher les journaux.

• Dans Orchestrator, accédez au dossier des pipelines dédié > Automations > Tâches. Dans la colonne Source , recherchez la balise Pipelines , puis sélectionnez Afficher les journaux.

Suppression manuelle des Webhooks

Si le pipeline était configuré pour s'exécuter pour chaque validation lors de la création, des webhooks étaient automatiquement créés dans GitHub/Azure DevOps.

Après avoir supprimé la configuration du runtime, vous devez supprimer manuellement les Webhooks si le lien de contrôle de code source avec le pipeline a déjà été supprimé. Bien que leur suppression n’affecte pas la fonctionnalité du service CI/CD, nous avons recommandé cette étape.

Pour chaque pipeline ayant un déclencheur lors de la validation et dont la connexion au contrôle de code source a été supprimée, vous devez accéder au référentiel GitHub/Azure DevOps et supprimer les Webhooks après avoir supprimé l'environnement du runtime.

Important :

Si la connexion au contrôle de code source a déjà été supprimée dans votre organisation et que ce référentiel est actuellement connecté à une autre organisation UiPath, vous pouvez supprimer des webhooks valides de la deuxième organisation. Ceux-ci ne doivent pas être supprimés, sinon les pipelines ne seront pas déclenchés lors de la validation.

Par conséquent, avant de supprimer les Webhooks, assurez-vous que le référentiel actuel ne dispose pas d'une connexion valide dans une configuration de runtime CI/CD valide dans une organisation UiPath.

Suppression des webhooks du référentiel GitHub

Pour supprimer les Webhooks du référentiel GitHub :

1. Accédez au référentiel Github et sélectionnez Paramètres > Webhooks.

   

2. Supprimez toutes les URL des Webhooks qui se terminent par /roboticsops_/cicd_/api/webhooks/github/pipeline.

   

Suppression des webhooks du référentiel Azure DevOps

Pour supprimer les webhooks du référentiel Azure DevOps :

1. Accédez au référentiel Azure DevOps et sélectionnez Paramètres du projet > Connexions au service.

2. Dans le webhook à supprimer, sélectionnez Modifier.

   

3. Assurez-vous que l'URL du Webhook se termine par /roboticsops_/cicd_/api/webhooks/azure/pipeline.

   

   

4. Supprimer l'URL du Webhook.