UiPath® Automation Ops™ – Pipelines

Automation Ops™ – Pipelines bieten eine einfache Möglichkeit, ein System für kontinuierliche Integration/kontinuierliche Auslieferung 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 des Codes in Ihrer Umgebung verwendet werden. Diese Prozesse, die auch Pipelineprozesse genannt werden, verwenden das Pipeline- Aktivitätspaket. Damit ein Benutzer diese Pipelineprozesse überprüfen kann, muss er 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 für die Ausführung als Hintergrundprozess konfiguriert werden. Dies geschieht über das Projekteinstellungsmenü in Studio. Erfahren Sie mehr über Hintergrundprozesse.
  • Achten Sie beim Veröffentlichen des Pipelineprozesses von Studio in Orchestrator darauf, auch Quellen einschließen im Abschnitt Veröffentlichungsoptionen auszuwählen. Lesen Sie mehr über die Veröffentlichung von Automatisierungsprojekten.

Konfiguration

Automation Ops™- Pipelines funktionieren durch die Ausführung von Pipelineprozessen mit Unattended-Robotern. Das bedeutet, dass vor ihrer Verwendung eine bestimmte Konfiguration im Orchestrator erforderlich ist. 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 ihrem Namen ausgeführt. Das Löschen des Roboterkontos führt zu einer ungültigen Konfiguration der Pipeline-Laufzeit und dazu, dass die Schnelleinrichtung erneut ausgeführt werden muss.

Wenn Sie den dedizierten Pipelines-Ordner im Orchestrator löschen, werden alle ihm zugeordneten 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 Ziel-Orchestrator-Ordner 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 Standardpipeline-Prozesse verfügen über einen eigenen Satz von Argumenten. Beispielsweise hat Erstellen.und.mit.Zulassung fördern . die folgenden Argumente:

• Testen überspringen (SkipTesting) – Ermöglicht es Ihnen, zu wählen, ob die Testfälle während der Pipeline ausgeführt werden oder nicht.
• TestingFolder – Der Orchestrator-Ordner, in dem die Tests ausgeführt werden.
• AnalyzePolicy – Die Governance-Richtlinie, die die Workflow-Analyseregeln enthält, die im Pipelineprozess verwendet werden. Wenn leer gelassen, wird die Analyse des Projekts übersprungen.
• Validierung überspringen (SkipValidation) – Ermöglicht es Ihnen, die Validierung vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
• Genehmiger – Die E-Mail-Adresse des Genehmigers der im Action Center erstellten Aufgabe.
• FirstOrchestratorUrl – Die URL des Orchestrators, in dem das erstellte Paket veröffentlicht wird.
• FirstOrchestratorFolder – Der Orchestrator-Ordner, in dem das erstellte Paket veröffentlicht wird.
• ZweiteOrchestratorUrl – Die URL zum Orchestrator, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
• ZweiterOrchestrator- Ordner – Der Orchestrator-Ordner, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
• GleichesPaketFeedHaben - Dieses Feld ist standardmäßig auf „False“ festgelegt. Legen Sie ihn auf „True“ fest, wenn die erste und zweite Umgebung denselben Paket-/Bibliotheksfeed verwenden.
• Prozessname – Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn es sich bei dem Projekt um einen Prozess handelt.

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 die Standardgröße . Wenn es sich bei der Aktivität RunTests um einen Orchestrator-Ordner mit Cloud Serverless-Robotern handelt, stellen Sie sicher, dass die Roboter die Standardgröße haben.

Ü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 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 Sie das externe Repository mit Source Control verbunden haben, wird es automatisch verbunden.
   Hinweis: Es kann nur eine UiPath® Automation Cloud™-Organisation 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 aus (optional). Wählen Sie Weiter aus.
   
   
   
   
4. Auf der Registerkarte Pipelinedefinition :
   • Wählen Sie 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:
     • Bei jedem Commit – Die Pipelineautomatisierung wird jedes Mal ausgelöst, wenn sich der Code im Repository für das ausgewählte Projekt ändert.
     • Ich werde manuell ausführen – Die Pipelineautomatisierung wird manuell ausgelöst.
       Hinweis:

       Bei manuell ausgelösten Pipelines ist der Commit, der beim Starten eines Auftrags verwendet wird, der 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 bei 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 sie auch auszuführen.

Wichtig:

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

Das ProjectPath -Argument wird mit dem Wert aufgefüllt, der im Feld Automation project (optional) aus dem Standort -Schritt von der Pipelinekonfiguration ausgewählt wurde.

Wenn das Feld leer bleibt, bleibt das Prozessargument ProjectPath 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 Ausführung der Pipeline ausgelöst, und Sie können den Fortschritt für jeden Schritt 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 Pipelinedefinition können nicht geändert werden.

• Pipeline löschen – Wählen Sie diese Option aus, um die Pipeline zu löschen (alle Informationen im Zusammenhang mit der 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

The latest versions of the pre-defined pipeline templates are available in the Marketplace.

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

• Erstellen.und.Betreiben.Sie.mit.Genehmigungsprozess :
  • Prozessname – Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn es sich bei dem Projekt um einen Prozess handelt.
  • Genehmiger – Die E-Mail-Adresse des Genehmigers der im Action Center erstellten Aufgabe.
  • Testen überspringen (SkipTesting) – Ermöglicht es Ihnen, zu wählen, ob die Testfälle während der Pipeline ausgeführt werden oder nicht.
  • AnalyzePolicy – Die Governance-Richtlinie, die die Workflow-Analyseregeln enthält, die im Pipelineprozess verwendet werden. Wenn leer gelassen, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen (SkipValidation) – Ermöglicht es Ihnen, die Validierung vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
  • FirstOrchestratorFolder – Der Orchestrator-Ordner, in dem das erstellte Paket veröffentlicht wird.
  • FirstOrchestratorUrl – Die URL des Orchestrators, in dem das erstellte Paket veröffentlicht wird.
  • ZweiterOrchestrator- Ordner – Der Orchestrator-Ordner, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
  • ZweiteOrchestratorUrl – Die URL zum Orchestrator, in dem das erstellte Paket nach der Genehmigung veröffentlicht wird.
  • TestingFolder – Der Orchestrator-Ordner, in dem die Tests ausgeführt werden.
  • GleichesPaketFeedHaben - Dieses Feld ist standardmäßig auf „False“ festgelegt. Legen Sie ihn auf „True“ fest, wenn die erste und zweite Umgebung denselben Paket-/Bibliotheksfeed verwenden.
• Build.and.publish
  • AnalyzePolicy – Die Governance-Richtlinie, die die Workflow-Analyseregeln enthält, die im Pipelineprozess verwendet werden. Wenn leer gelassen, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen (SkipValidation) – Ermöglicht es Ihnen, die Validierung vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl – Die URL des Orchestrators, auf 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 (IsLibrary) - Definiert, ob es sich bei dem Paket um eine Bibliothek handelt oder nicht.
  • PaketVersion (PackageVersion) - Die Version des zu kopierenden Pakets.
  • SourceOrchestratorFolder – Der Orchestrator-Ordner, aus dem das Paket kopiert wird.
  • SourceOrchestratorUrl – Die URL zum Orchestrator, von dem das Paket kopiert wird.
  • DestinationOrchestratorUrl – Die URL des Orchestrators, in den das Paket kopiert wird.
  • DestinationOrchestratorFolder – Der Orchestrator-Ordner, in den das Paket kopiert wird.
• Update.process.from.code
  • Prozessname – Der Name des zu aktualisierenden Prozesses. Wird nur verwendet, wenn es sich bei dem Projekt um einen Prozess handelt.
  • AnalyzePolicy – Die Governance-Richtlinie, die die Workflow-Analyseregeln enthält, die im Pipelineprozess verwendet werden. Wenn leer gelassen, wird die Analyse des Projekts übersprungen.
  • Validierung überspringen (SkipValidation) – Ermöglicht es Ihnen, die Validierung vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl - Die URL zum Orchestrator, in dem sich das zu aktualisierende Paket befindet.
  • 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 es sich bei dem Projekt um einen Prozess handelt.
  • AnalyzePolicy – Die Governance-Richtlinie, die die Workflow-Analyseregeln enthält, die im Pipelineprozess verwendet werden. Wenn leer gelassen, wird die Analyse des Projekts übersprungen.
  • Testen überspringen – Ermöglicht es Ihnen, Tests vor dem Erstellen des Pakets zu überspringen. Dieser Wert ist standardmäßig deaktiviert.
  • OrchestratorUrl - Die URL zum Orchestrator, in dem sich das zu aktualisierende Paket befindet.
  • Orchestrator -Ordner – Der Orchestrator-Ordner, in dem sich das zu aktualisierende Paket befindet.
  • OrchestratorTestingFolder – Der Orchestrator-Ordner, in dem die in der Pipeline verwendeten Tests zu finden sind.

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ägezu. Suchen Sie in der Spalte Quelle nach dem Tag Pipelines und wählen Sie dann Protokolle anzeigenaus.

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 Settings > 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 auf dem zu löschenden Webhook 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.