UiPath® Automation Ops™ - Pipelines

Automation Ops™ - Les pipelines offrent un moyen simple de configurer un système d'intégration/de livraison continue pour 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 ( Pipeline Processes), utilisent le package d' activités Pipeline . Pour qu'un utilisateur puisse voir 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. Cela se fait à partir du 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 des 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 runtime du pipeline.

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 il est nécessaire 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 dans les pipelines, Allow to be Automation User, Allow to be Automation Publisher
• Dossier des pipelines: rôle du dossier des pipelines, utilisateur d'automatisation, éditeur d'automatisation

Remarque :

Assurez-vous que le compte Robot créé pour les pipelines est également affecté au dossier Orchestrator cible. Il est nécessaire puisque les pipelines fonctionnent sous ce compte. Pour plus de détails, voir Configuration de l'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.

En outre, les processus de pipelines prédéfinis suivants sont 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

Ces processus de pipelines par défaut sont livrés avec leur propre ensemble d'arguments, par exemple, Créer.et.promouvoir.avec.approbation contient les arguments suivants :

• IgnorerTesting : permet de choisir si les cas de test sont exécutés ou non pendant le pipeline.
• DossierTest (TestingFolder) - Dossier Orchestrator dans lequel les tests sont exécutés.
• AnalyzePolicy : la stratégie de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si laissé vide, l'analyse du projet sera ignorée.
• Ignorer la validation (SkipValidation) - 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.
• FirstOrchestratorUrl : URL de l'instance d'Orchestrator où le package créé est publié.
• PremierDossierOrchestrator (FirstOrchestratorFolder) - Dossier Orchestrator dans lequel le package créé est publié.
• SecondOrchestratorUrl : URL de l'instance 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.
• HaveSamePackageFeed : ce champ est défini sur «False» par défaut. Définissez-le sur « True » si le premier et le deuxième environnements utilisent le même flux de package/bibliothèque.
• NomProcessus (ProcessName) - Nom du processus à mettre à jour. Utilisé uniquement si le projet est un processus.

Vous pouvez également commencer à travailler avec les pipelines en utilisant les 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 sans serveur créés dans la configuration initiale sont de taille standard . Lorsque vous utilisez l'activité RunTests, si elle implique 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 créé 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 (New Pipeline). Si le référentiel externe est connecté à Source Control , il est automatiquement connecté ici également.
   Remarque : une seule organisation UiPath® Automation Cloud™ peut être connectée à une organisation GitHub en même temps.
3. Dans l'onglet Emplacement (Location), sélectionnez l'organisation de référentiel externe, le référentiel, la branche et un projet d'automatisation (facultatif). Cliquez sur Suivant.
   
   
   
   
4. Dans l'onglet Définition du pipeline ( Pipeline definition ) :
   • Sélectionner 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 ( Save & run ), configurez les éléments suivants :
   • Nom du projet : saisissez un nom pour le projet de pipeline. Par défaut, le nom est composé à partir du nom du référentiel et du nom du projet d'automatisation du pipeline.
   • Description : si vous le souhaitez, ajoutez une description.
   • Exécuter ce pipeline (Run this pipeline ) - Sélectionnez le mode d'exécution du pipeline :
     • Pour chaque validation : l'automatisation du pipeline est déclenchée à chaque fois qu'il y a une modification de code dans le référentiel pour le projet sélectionné.
     • J'exécuterai manuellement - L'automatisation du pipeline est déclenchée manuellement.
       Remarque :

       Sur les pipelines déclenchés manuellement, la validation utilisée au démarrage d'une tâche est la dernière validation dans le dossier du fichier project.json sélectionné.

       Il ne s'agit pas de la dernière validation de l'ensemble du référentiel si aucun fichier de ce dossier n'est modifié dans cette validation.

6. Cliquez sur Enregistrer ( Save) pour enregistrer le pipeline ou sur Enregistrer et exécuter ( Save and run) pour enregistrer et également exécuter le pipeline.

Important :

Si aucun processus spécifique du référentiel n'est choisi à l'étape 1 (aucun projet d'automatisation sélectionné) et que le pipeline est configuré 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 Emplacement de la configuration du pipeline.

Si le champ est laissé vide, l'argument de processus ProjectPath restera 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™ à partir de 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 (Start new job) . Cela déclenche l'exécution du pipeline et vous pouvez voir la progression de chaque étape en temps réel.

À partir de là, vous pouvez également modifier le pipeline en sélectionnant Paramètres du pipeline ( Pipeline settings). Cela affichera le résumé du pipeline, à partir duquel vous pourrez :

• Modifier le pipeline (Edit 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 ( Delete pipeline ) : sélectionnez pour supprimer le pipeline (toutes les informations relatives au pipeline seront supprimées).

Processus de pipeline prédéfinis

Les processus de pipelines prédéfinis suivants sont 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

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

• Processus.de.création.et.de.promotion.avec.approbation :
  • NomProcessus (ProcessName) - Nom du processus à mettre à jour. Utilisé uniquement si le projet est un processus.
  • Approbateur - L'adresse e-mail de l'approbateur de la tâche créée dans Action Center.
  • IgnorerTesting : permet de choisir si les cas de test sont exécutés ou non pendant le pipeline.
  • AnalyzePolicy : la stratégie de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si laissé vide, l'analyse du projet sera ignorée.
  • Ignorer la validation (SkipValidation) - Vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • PremierDossierOrchestrator (FirstOrchestratorFolder) - Dossier Orchestrator dans lequel le package créé est publié.
  • FirstOrchestratorUrl : URL de l'instance d'Orchestrator où le package créé est publié.
  • SecondOrchestratorFolder : le dossier Orchestrator dans lequel le package créé est publié après approbation.
  • SecondOrchestratorUrl : URL de l'instance d'Orchestrator où le package créé est publié après approbation.
  • DossierTest (TestingFolder) - Dossier Orchestrator dans lequel les tests sont exécutés.
  • HaveSamePackageFeed : ce champ est défini sur «False» par défaut. Définissez-le sur « True » si le premier et le deuxième environnements utilisent le même flux de package/bibliothèque.
• Build.and.publish
  • AnalyzePolicy : la stratégie de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si laissé vide, l'analyse du projet sera ignorée.
  • Ignorer la validation (SkipValidation) - Vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • URL d'Orchestrator (OrchestratorUrl) - URL de l'instance d'Orchestrator où le package créé est publié.
  • Dossier Orchestrator (OrchestratorFolder) - Dossier Orchestrator dans lequel le package créé est publié.
• Copy.package.between.environments
  • Nom du package(PackageName) - Nom du package à copier.
  • IsLibrary : définit si le package est une bibliothèque ou non.
  • PackageVersion : la version du package à copier.
  • SourceOrchestratorFolder : le dossier Orchestrator à partir duquel le package est copié.
  • SourceOrchestratorUrl : URL de l'Orchestrator à partir duquel le package est copié.
  • DestinationOrchestratorUrl : URL de l'Orchestrator où le package est copié.
  • Dossier Orchestrator de destination (DestinationOrchestratorFolder ) - Le dossier Orchestrator dans lequel le package est copié.
• Update.process.from.code
  • NomProcessus (ProcessName) - Nom du processus à mettre à jour. Utilisé uniquement si le projet est un processus.
  • AnalyzePolicy : la stratégie de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si laissé vide, l'analyse du projet sera ignorée.
  • Ignorer la validation (SkipValidation) - Vous permet d'ignorer la validation avant de créer le package. Cette valeur est désactivée par défaut.
  • URL d'Orchestrator (OrchestratorUrl) - URL de l'instance d'Orchestrator où se trouve le paquet à mettre à jour.
  • Dossier Orchestrator (OrchestratorFolder) - Dossier Orchestrator dans lequel se trouve le package à mettre à jour.
• Update.with.tests
  • NomProcessus (ProcessName) - Nom du processus à mettre à jour. Utilisé uniquement si le projet est un processus.
  • AnalyzePolicy : la stratégie de gouvernance contenant les règles de l'analyseur de workflow utilisées dans le processus de pipeline. Si laissé vide, l'analyse du projet sera ignorée.
  • Ignorer les tests (SkipTesting ) : permet d'ignorer les tests avant de créer le package. Cette valeur est désactivée par défaut.
  • URL d'Orchestrator (OrchestratorUrl) - URL de l'instance d'Orchestrator où se trouve le paquet à mettre à jour.
  • Dossier Orchestrator (OrchestratorFolder) - Dossier Orchestrator dans lequel se trouve le package à mettre à jour.
  • Dossier de test d'Orchestrator (OrchestratorTestingFolder) - Dossier Orchestrator dans lequel 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 l'ensemble d'arguments par défaut suivant pour le processus de pipeline :

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 ( View Logs).

• Dans Orchestrator, accédez au dossier de pipelines dédié > Automatisations (Automations) > Tâches ( Jobs). Dans la colonne Source , recherchez la balise Pipelines , puis sélectionnez Afficher les journaux ( View Logs).

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 (Settings) > Webhooks (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 > Hooks de service.
2. Sur le Webhook à supprimer, sélectionnez Modifier(Edit).
   
3. Assurez-vous que l'URL du Webhook se termine par /roboticsops_/cicd_/api/webhooks/azure/pipeline.
   
   
4. Supprimer l'URL du Webhook.