UiPath® Automation Ops™ – Pipelines

Automation Ops™ – Pipelines bieten eine einfache Möglichkeit, ein CI/CD-System einzurichten, um den Code Ihrer Automatisierungsprojekte in externen Repositorys wie Github oder Azure DevOps zu verwalten.

Pipelines enthalten eine Reihe von Schritten, die auf Automatisierungsprozessen basieren, die zum Ändern von Code in Ihrer Umgebung verwendet werden. Diese Prozesse, auch Pipelineprozesse genannt, verwenden das Pipelineaktivitätspaket . Damit Benutzer diese Pipelineprozesse überprüfen können, müssen sie Zugriff auf den Orchestrator-Ordner haben, der sie enthält.

Wenn eine Pipeline ausgelöst wird, wird ein Auftrag gestartet, der den zugehörigen Pipelineprozess mit einem Unattended-Roboter ausführt.

Voraussetzungen

• Roboterversionen:
  • 2021.10 und 2022.4: .NET Desktop Runtime 6.0.* muss manuell auf der Robotermaschine installiert werden.
  • 2022.8 und neuer: .NET Desktop Runtime wird automatisch mit dem Roboter installiert.
• Besonderheiten des Prozesses:
  • Der Pipelineprozess muss so konfiguriert werden, dass er als Prozess im Hintergrund ausgeführt wird. Dies geschieht über das Menü „Projekteinstellungen“ in Studio. Hier erfahren Sie mehr über Hintergrundprozesse.
  • Achten Sie beim Veröffentlichen des Pipelineprozesses von Studio im Orchestrator darauf, im Abschnitt Veröffentlichungsoptionen auch Quellen einschließen auszuwählen. Weitere Informationen über die Veröffentlichung von Automatisierungsprojekten.

Konfiguration

Automation Ops™- Pipelines funktionieren durch die Ausführung von Pipelineprozessen mit Unattended-Robotern. Das bedeutet, dass eine bestimmte Konfiguration im Orchestrator erforderlich ist, bevor sie verwendet werden können. Diese Konfiguration wird als Pipeline-Laufzeitumgebung bezeichnet.

Die grundlegende Orchestrator-Konfiguration verfügt über einen dedizierten Ordner, der die Pipelineprozesse und ein Roboterkonto enthält, sowie eine Maschinen- oder Maschinenvorlage zum Ausführen der Pipelineaufträge.

Wichtig:

Das während der Schnelleinrichtung erstellte Roboterkonto ist unerlässlich. Alle Pipelines (Orchestrator-Aufträge) werden in seinem Namen ausgeführt. Das Löschen des Roboterkontos führt zu einer ungültigen Pipeline-Laufzeitkonfiguration und dazu, dass die Schnelleinrichtung erneut ausgeführt werden muss. Wenn Sie den dedizierten Pipelines-Ordner im Orchestrator löschen, werden alle mit ihm verbundenen Pipelines unterbrochen.

Ersteinrichtung

Beim ersten Einrichten von Automation Ops™ – Pipelines wird ein Fenster für die schnelle Einrichtung angezeigt, in dem Sie den Mandanten und den Maschinentyp auswählen können, mit dem Sie die zukünftigen Pipelines ausführen möchten. Sie können wählen, ob Sie eine vorhandene Maschine aus Ihrer Umgebung verwenden oder automatisch eine neue serverlose Maschine namens „Pipelines Robot“ erstellen.

Hinweis:

Wenn Sie eine neue serverlose Maschine erstellen, stellen Sie sicher, dass genügend Robot Units auf Ihrem Mandanten verfügbar sind.

Als Teil der Schnelleinrichtung werden automatisch ein neuer Ordner mit dem Namen „Pipelines“ und die folgenden Rollen erstellt:

• Pipeline-Mandantenrolle
• Ordnerrolle „Pipelines“

Dem Pipelines-Roboter werden die folgenden Rollen automatisch zugewiesen:

• Mandant: Pipeline-Mandantenrolle, Allow to be Automation User, Allow to be Automation Publisher
• Pipelines-Ordner: Pipelines-Ordnerrolle, Automation User, Automation Publisher

Hinweis:

Stellen Sie sicher, dass das für Pipelines erstellte Roboterkonto auch dem Orchestrator-Zielordner zugewiesen ist. Dies ist erforderlich, da Pipelines unter diesem Konto ausgeführt werden. Weitere Informationen finden Sie unter Konfigurieren des Zugriffs für Konten.

Die Aktivität Run Tests führt die Tests im angegebenen Orchestrator-Ordner aus. Das Pipelines-Roboterkonto veröffentlicht das Paket im jeweiligen Ordner, aber die Tests können von jedem Roboterkonto in diesem Ordner ausgeführt werden, das sich für die Testausführung qualifiziert, nicht nur vom Pipelines-Roboterkonto.

Darüber hinaus sind die vordefinierten Pipelineprozesse standardmäßig verfügbar, wie in der folgenden Tabelle dargestellt:

Build.and.publish	Klonen -> Analysieren -> Erstellen -> Veröffentlichen
Copy.package.between.environments	Paket herunterladen -> Paket veröffentlichen
Update.process.from.code	Klonen -> Analysieren -> Erstellen -> Paket veröffentlichen -> Prozess aktualisieren
Update.with.tests	Klonen -> Analysieren -> Tests ausführen -> Erstellen -> Paket veröffentlichen -> Prozess aktualisieren
Build.and.promote.with.approval	Klonen -> Analysieren -> Tests ausführen -> Build -> Paket veröffentlichen -> Prozess aktualisieren -> Genehmigen -> Paket herunterladen -> Paket hochladen -> Prozess aktualisieren

Diese Standardpipelineprozesse verfügen über einen eigenen Satz von Argumenten, beispielsweise hat Build.and.promote.with.approval die folgenden Argumente:

• Überspringen – Ermöglicht die Auswahl, ob die Testfälle während der Pipeline ausgeführt werden oder nicht.
• TestingFolder – Der Orchestrator-Ordner, in dem die Tests ausgeführt werden.
• Analyserichtlinie – Die Governance-Richtlinie, die die im Pipelineprozess verwendeten Workflow-Analyseregeln enthält. Wenn dies leer gelassen wird, wird die Analyse des Projekts übersprungen.
• Validierung überspringen – Ermöglicht das Überspringen der Validierung vor dem Erstellen des Pakets. Dieser Wert ist standardmäßig deaktiviert.
• Genehmiger – Die E-Mail-Adresse des Genehmigers der im Action Center erstellten Aufgabe.
• FirstOrchestratorUrl – Die URL zum Orchestrator, in dem das erstellte Paket veröffentlicht wird.
• ErsterOrchestratorOrdner – Der Orchestrator-Ordner, in dem das erstellte Paket veröffentlicht wird.
• ZweiteOrchestratorURL – Die URL zum Orchestrator, in der das erstellte Paket nach der Genehmigung veröffentlicht wird.
• ZweiterOrchestratorOrdner – Der Orchestrator-Ordner, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
• HabenSamePackageFeed – Dieses Feld ist standardmäßig auf „ False “ festgelegt. Legen Sie ihn auf „True“ fest, wenn erste und zweite Umgebungen denselben Paket-/Bibliotheksfeed verwenden.
• ProzessName - Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn das Projekt Prozess ist.

Sie können auch mit Pipelines arbeiten, indem Sie die in UiPath Studio und Studio Web verfügbaren Vorlagen verwenden (Registerkarte Vorlagen ).

Sie können die folgenden Vorlagen verwenden:

• Build and promote with approval pipeline:

  • Verwendung: Management eines Automatisierungsprojekts von der Idee bis zur Genehmigung.
  • Schritte: Klonen, Analysieren, Test ausführen, Erstellen, Veröffentlichen des Pakets, Aktualisieren des Prozesses, Genehmigen, Paket herunterladen, Paket hochladen und Paket aktualisieren.

• Update process from a code line:

  • Verwendung: Hebt ein optimiertes Verfahren für Aktualisierungen und Änderungen an laufenden Prozessen hervor.
  • Schritte: Klonen, Analysieren, Erstellen, Veröffentlichen des Pakets und Prozess aktualisieren.

Wichtig:

Cloud Serverless-Roboter, die bei der Ersteinrichtung erstellt wurden, haben Standardgröße . Stellen Sie bei Verwendung der RunTests-Aktivität sicher, dass die Roboter eine Standardgröße haben, wenn es sich um einen Orchestrator-Ordner mit Cloud Serverless-Robotern handelt.

Überprüfen Sie bei Verwendung der Aktivität Build die Kompatibilitätsanforderungen zwischen den Automatisierungsprojekten, die Sie erstellen, und der Maschine, auf der der Prozess ausgeführt wird.

Beispielsweise kann ein Projekt, das mit der Windows-Legacy or Windows -Kompatibilität erstellt wurde, nicht auf einem Cloud Serverless-Roboter erstellt werden. Sie müssen stattdessen eine Windows -basierte Maschine verwenden.

Stellen Sie beim Ausführen einer Pipeline, die einen Prozess mithilfe von Integration Service-Verbindungen generiert und veröffentlicht, sicher, dass alle erforderlichen Projektordner an Ihren Source Control-Anbieter gebunden sind. Beispielsweise ist es erforderlich, beim Initialisieren von Git in Studio alle zugehörigen Projektordner zu übergeben, z. B. .settings, .project, .tmh.

Erstellen der ersten Pipeline

Nachdem das Orchestrator-Setup abgeschlossen ist, müssen Sie die erste Integration zwischen Automation Ops™-Pipelines, dem GitHub-Repository, das Ihren Code enthält, und der Laufzeitumgebung der Orchestrator-Pipelines konfigurieren. Bei dieser Integration erstellen Sie auch die erste Pipeline.

Führen Sie diese Schritte aus:

1. Navigieren Sie in der Automation Cloud™ über die linke Navigationsleiste zu Automation Ops™ > Pipelines .

2. Wählen Sie Neue Pipeline aus. Wenn das externe Repository mit der Source Control verbunden ist, wird es automatisch verbunden.

   Hinweis:

   Nur eine UiPath® Automation Cloud™-Organisation kann gleichzeitig mit einer GitHub-Organisation verbunden werden.

3. Wählen Sie auf der Registerkarte Speicherort die externe Repository-Organisation, das Repository, die Verzweigung und ein Automatisierungsprojekt (Optional) aus. Wählen Sie Weiter.

   

4. Wählen Sie auf der Registerkarte Pipelinedefinition den Pipelineprozess aus. Wenn Ihr Pipelineprozess Argumente enthält, können Sie deren Werte hinzufügen.
   

5. Konfigurieren Sie auf der Registerkarte Speichern und ausführen Folgendes:

   • Projektname – Geben Sie einen Namen für das Pipelineprojekt ein. Standardmäßig besteht der Name aus dem Namen des Repositorys und dem Namen des Pipeline-Automatisierungsprojekts.
   • Beschreibung – Fügen Sie optional eine Beschreibung hinzu.
   • Diese Pipeline ausführen – Wählen Sie aus, wie die Pipeline ausgeführt werden soll:
     • Für jeden Commit – Die Pipelineautomatisierung wird jedes Mal ausgelöst, wenn sich der Code im Repository für das ausgewählte Projekt ändert.
     • Manuelle Ausführung – Die Pipeline-Automatisierung wird manuell ausgelöst.
       Hinweis:

       Bei manuell ausgelösten Pipelines ist das beim Starten eines Auftrags verwendete Commit das letzte Commit im Ordner der ausgewählten project.json -Datei. Es ist nicht der letzte Commit im gesamten Repository, wenn keine Dateien in diesem Ordner in diesem Commit geändert werden.

6. Wählen Sie Speichern aus, um die Pipeline zu speichern, oder Speichern und ausführen, um die Pipeline zu speichern und auszuführen.

Wichtig:

Wenn in Schritt 1 kein bestimmter Prozess aus dem Repository ausgewählt ist (kein Automatisierungsprojekt ausgewählt) und die Pipeline so eingestellt ist, dass sie durch einen Commit ausgelöst wird, wird die Pipeline durch jeden Commit im Repository ausgelöst.

Das ProjectPath -Argument wird mit dem Wert aufgefüllt, der im Automation project (optional) -Feld aus dem Speicherort- Schritt der Pipelinekonfiguration ausgewählt wurde. Wenn das Feld leer gelassen wird, bleibt das ProjectPath -Prozessargument leer. Dieses Szenario kann für Repositorys verwendet werden, die nur ein Automatisierungsprojekt haben.

Manuelles Ausführen einer Pipeline

1. Navigieren Sie in der Automation Cloud™ über die linke Navigationsleiste zu Automation Ops™ .
2. Wählen Sie Pipelines aus. Die verfügbaren Pipelines werden angezeigt.
3. Wählen Sie eine Pipeline und dann Neuen Auftrag starten aus. Dadurch wird die Pipeline ausgeführt und Sie können den Fortschritt jedes Schritts in Echtzeit verfolgen.

Sie können die Pipeline auch bearbeiten, indem Sie Pipelineeinstellungen auswählen. Dadurch wird die Pipelinezusammenfassung angezeigt, von der aus Sie:

• Pipeline bearbeiten – Wählen Sie diese Option aus, um Aktualisierungen an der Pipeline vorzunehmen. Sie können nur den Pipeline-Namen, die Beschreibung, den Triggertyp und benutzerdefinierte Pipeline-Argumente aktualisieren. Speicherort und Pipeline-Definition können nicht geändert werden.
• Pipeline löschen – Wählen Sie aus, um die Pipeline zu löschen (alle Informationen zur Pipeline werden gelöscht).

Vordefinierte Pipelineprozesse

In der folgenden Tabelle werden die vordefinierten Pipelineprozesse beschrieben, die standardmäßig verfügbar sind:

Build.and.publish	Klonen -> Analysieren -> Erstellen -> Veröffentlichen
Copy.package.between.environments	Paket herunterladen -> Paket veröffentlichen
Update.process.from.code	Klonen -> Analysieren -> Erstellen -> Paket veröffentlichen -> Prozess aktualisieren
Update.with.tests	Klonen -> Analysieren -> Tests ausführen -> Erstellen -> Paket veröffentlichen -> Prozess aktualisieren
Build.and.promote.with.approval	Klonen -> Analysieren -> Tests ausführen -> Build -> Paket veröffentlichen -> Prozess aktualisieren -> Genehmigen -> Paket herunterladen -> Paket hochladen -> Prozess aktualisieren

Die neuesten Versionen der vordefinierten Pipelinevorlagen sind im Marketplace verfügbar.

Diese Standard-Pipeline-Prozesse verfügen über den folgenden Satz von Argumenten:

• Prozess zum Erstellen und Umstufen mit Genehmigung :
  • ProzessName - Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn das Projekt Prozess ist.
  • Genehmiger – Die E-Mail-Adresse des Genehmigers der im Action Center erstellten Aufgabe.
  • Überspringen – Ermöglicht die Auswahl, ob die Testfälle während der Pipeline ausgeführt werden oder nicht.
  • Analyserichtlinie – Die Governance-Richtlinie, die die im Pipelineprozess verwendeten Workflow-Analyseregeln enthält. Wenn dies leer gelassen wird, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen – Ermöglicht das Überspringen der Validierung vor dem Erstellen des Pakets. Dieser Wert ist standardmäßig deaktiviert.
  • ErsterOrchestratorOrdner – Der Orchestrator-Ordner, in dem das erstellte Paket veröffentlicht wird.
  • FirstOrchestratorUrl – Die URL zum Orchestrator, in dem das erstellte Paket veröffentlicht wird.
  • ZweiterOrchestratorOrdner – Der Orchestrator-Ordner, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
  • ZweiteOrchestratorURL – Die URL zum Orchestrator, in der das erstellte Paket nach der Genehmigung veröffentlicht wird.
  • TestingFolder – Der Orchestrator-Ordner, in dem die Tests ausgeführt werden.
  • HabenSamePackageFeed – Dieses Feld ist standardmäßig auf „ False “ festgelegt. Legen Sie ihn auf „True“ fest, wenn erste und zweite Umgebungen denselben Paket-/Bibliotheksfeed verwenden.
• Build.and.publish
  • Analyserichtlinie – Die Governance-Richtlinie, die die im Pipelineprozess verwendeten Workflow-Analyseregeln enthält. Wenn dies leer gelassen wird, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen – Ermöglicht das Überspringen der Validierung vor dem Erstellen des Pakets. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl – Die URL zum Orchestrator, in dem das erstellte Paket veröffentlicht wird.
  • Orchestrator-Ordner – Der Orchestrator-Ordner, in dem das erstellte Paket veröffentlicht wird.
• Copy.package.between.environments
  • PaketName - Der Name des zu kopierenden Pakets.
  • IstBibliothek - Definiert, ob das Paket eine Bibliothek ist oder nicht.
  • Paketversion – Die Version des zu kopierenden Pakets.
  • QuellOrchestratorOrdner – Der Orchestrator-Ordner, aus dem das Paket kopiert wird.
  • SourceOrchestratorUrl – Die URL zum Orchestrator, aus der das Paket kopiert wird.
  • ZielOrchestratorURL – Die URL zum Orchestrator, in den das Paket kopiert wird.
  • ZielOrchestratorOrdner – Der Orchestrator-Ordner, in den das Paket kopiert wird.
• Update.process.from.code
  • ProzessName - Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn das Projekt Prozess ist.
  • Analyserichtlinie – Die Governance-Richtlinie, die die im Pipelineprozess verwendeten Workflow-Analyseregeln enthält. Wenn dies leer gelassen wird, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen – Ermöglicht das Überspringen der Validierung vor dem Erstellen des Pakets. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl – Die URL zum Orchestrator, unter der das zu aktualisierende Paket zu finden ist.
  • Orchestrator-Ordner – Der Orchestrator-Ordner, in dem sich das zu aktualisierende Paket befindet.
• Update.with.tests
  • ProzessName - Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn das Projekt Prozess ist.
  • Analyserichtlinie – Die Governance-Richtlinie, die die im Pipelineprozess verwendeten Workflow-Analyseregeln enthält. Wenn dies leer gelassen wird, wird die Analyse des Projekts übersprungen.
  • Tests überspringen – Ermöglicht es Ihnen, Tests vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl – Die URL zum Orchestrator, unter der das zu aktualisierende Paket zu finden ist.
  • Orchestrator-Ordner – Der Orchestrator-Ordner, in dem sich das zu aktualisierende Paket befindet.
  • OrchestratorTestingFolder – Der Orchestrator-Ordner, in dem sich die in der Pipeline verwendeten Tests befinden.

Hinweis:

Es gibt eine Kompatibilitätsanforderung zwischen den Automatisierungsprojekten, die Sie erstellen möchten, und der Maschine, auf der der Pipelineprozess ausgeführt wird.

Die richtige Zuordnung ist:

• Windows-Legacy-Projekt → Build OS: nur Windows
• Windows-Projekt → Betriebssystem erstellen: nur Windows
• Plattformübergreifendes Projekt→ Build OS: Windows oder Linux

Standardargumente für Pipelineprozesse

Automation Ops™ bietet eine Reihe von Standardargumenten für den Pipeline-Prozess, die in der folgenden Tabelle dargestellt sind:

Name	Richtung	Argumenttyp	Beschreibung
Buildnummer	in	String	Eine eindeutige Zahl für jede Pipelineauftragsausführung.
Repository-URL	in	String	URL des Repositorys. Wird in der Regel von der Aktivität Klonen verwendet.
Commit-SHA	in	String	Commit-Bezeichner.
Projektpfad	in	String	Der Pfad zur project.json-Datei. Nützlich für die Aktivität Build.
ComitterBenutzername	in	String	Der Benutzername der Person, die den Commit auslöst.
RepositoryType	in	String	Der Repository-Typ (z. B. Git).
RepositoryBranch	in	String	Die verwendete Repository-Verzweigung.

Anzeigen von Pipelineprotokollen

Für jede Ausführung der Pipeline werden Protokolle generiert. Sie können die Protokolle in Automation Ops™ anzeigen. Und da jede Pipelineausführung einen Auftrag im Orchestrator erstellt, können Sie sie auch im Orchestrator anzeigen:

• Zeigen Sie in Automation Ops™ mit dem Mauszeiger auf den Bereich rechts neben einer Pipeline und wählen Sie dann im Kontextmenü die Option Protokolle anzeigen aus .

• Greifen Sie im Orchestrator auf den dedizierten Pipelines-Ordner > Automatisierungen > Aufträge zu. Suchen Sie in der Spalte Quelle nach dem Pipelines -Tag und wählen Sie dann Protokolle anzeigen aus.

Manuelles Entfernen von Webhooks

Wenn die Pipeline so eingerichtet wurde, dass sie für jeden Commit ausgeführt wird, dann wurden Webhooks automatisch in GitHub/Azure DevOps erstellt.

Nach dem Löschen der Laufzeitkonfiguration sollten Sie die Webhooks manuell entfernen, wenn die Source Control-Verknüpfung mit der Pipeline bereits entfernt wurde. Obwohl ihr Entfernen die Funktionalität des CI/CD-Diensts nicht beeinträchtigen würde, empfehlen wir diesen Schritt.

Für jede Pipeline, die beim Commit einen Trigger hat und deren Source Control-Verbindung entfernt wurde, müssen Sie auf das GitHub/Azure DevOps-Repository zugreifen und die Webhooks löschen, nachdem Sie die Laufzeitumgebung gelöscht haben.

Wichtig:

Wenn die Source Control-Verbindung in Ihrer Organisation bereits entfernt wurde und dieses Repository derzeit mit einer anderen UiPath-Organisation verbunden ist, können Sie gültige Webhooks aus der zweiten Organisation löschen. Diese dürfen nicht gelöscht werden, andernfalls werden Pipelines beim Commit nicht ausgelöst.

Stellen Sie daher vor dem Löschen von Webhooks sicher, dass das aktuelle Repository keine gültige Verbindung innerhalb einer gültigen CI/CD-Laufzeitkonfiguration in einer UiPath-Organisation hat.

Entfernen von Webhooks aus dem GitHub-Repository

So löschen Sie die Webhooks aus dem GitHub-Repository:

1. Wechseln Sie zum Github-Repository und wählen Sie Einstellungen > Webhooks aus.

   

2. Löschen Sie alle Webhook-URLs, die auf /roboticsops_/cicd_/api/webhooks/github/pipeline enden.

   

Entfernen von Webhooks aus dem Azure DevOps-Repository

So löschen Sie die Webhooks aus dem Azure DevOps-Repository:

1. Wechseln Sie zum Azure DevOps-Repository und wählen Sie Projekteinstellungen > Dienst-Hooks aus.

2. Wählen Sie an dem zu löschenden Webhook die Option Bearbeiten aus.

   

3. Stellen Sie sicher, dass die Webhook-URL mit /roboticsops_/cicd_/api/webhooks/azure/pipeline endet.

   

   

4. Löschen Sie die Webhook-URL.