Automation Ops

Neuestes

False

Versionshinweise
Einleitung
- Einleitung
- Lösungsverwaltung
Governance
Quellenkontrolle
- Quellenkontrolle
CI/CD-Pipelines
Verwalten von Feeds
Protokollierung
- Protokollierung

Automation Ops Benutzerhandbuch

Letzte Aktualisierung 26. Apr. 2024

UiPath Automation Ops – Pipelines

Automation Ops – Pipelines bietet 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 von Code in Ihrer Umgebung verwendet werden. Diese Prozesse, auch Pipelineprozesse genannt, verwenden das Aktivitätspaket Automation Ops – Pipelines . Damit ein Benutzer diese Pipelineprozesse sehen 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 so konfiguriert werden, dass er als Hintergrundprozess ausgeführt wird. Dies erfolgt über das Projekteinstellungsmenü in Studio. Hier erfahren Sie mehr über Hintergrundprozesse.
- Stellen Sie beim Veröffentlichen des Pipelineprozesses von Studio im Orchestrator sicher, dass Sie auch Quellen einschließen im Abschnitt Veröffentlichungsoptionen auswählen. Lesen Sie mehr über das Veröffentlichen von Automatisierungsprojekten.

Konfiguration

Automation Ops – Pipelines führen Pipelineprozesse mit Unattended Robotaus. Dies bedeutet, dass vor ihrer Verwendung eine bestimmte Konfiguration im Orchestrator erforderlich ist. Diese Konfiguration wird als Pipelines Runtime Umgebungbezeichnet.

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:

The robot account created during the quick setup is essential. All the pipelines (Orchestrator jobs) are ran on its behalf. Deleting the robot account causes an invalid pipeline runtime configuration and the need to rerun the quick setup.

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 Schnelleinrichtungsfenster 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 mit dem Namen „Pipelines Robot“ erstellen möchten.

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. Es wird benötigt, da Pipelines unter diesem Konto ausgeführt werden. Weitere Informationen finden Sie unter Konfigurieren des Zugriffs für Konten.

The Run Tests activity runs the tests in the provided Orchestrator folder. The Pipelines robot account publishes the package in the respective folder, but the tests can be run by any robot account in that folder that qualifies for the test run, not only by the Pipelines robot account.

Darüber hinaus sind die folgenden vordefinierten Pipelineprozesse standardmäßig verfügbar:

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.

Wichtig:

When using the Build activity, validate the compatibility requirements between the automation projects you are building and the machine running the process.

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 anfängliche 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:

Navigieren Sie in der Automation Cloud in der linken Navigationsleiste zu Automation Ops > Pipelines .
Wählen Sie Neue Pipeline aus. Wenn Sie das externe Repository mit Source Control verbunden haben, wird es hier auch automatisch verbunden.
Hinweis: Nur eine UiPath Automation Cloud-Organisation kann gleichzeitig mit einer GitHub-Organisation verbunden werden.
Wählen Sie auf der Registerkarte Speicherort die externe Repository-Organisation, das Repository, die Verzweigung und ein Automatisierungsprojekt (optional) aus. Klicken Sie auf Weiter.
Auf der Registerkarte Pipelinedefinition :
- Wählen Sie den Pipelineprozess aus. Wenn Ihr Pipelineprozess Argumente enthält, können Sie deren Werte hinzufügen.
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.
Klicken Sie auf Speichern , um die Pipeline zu speichern, oder auf Speichern und ausführen , um die Pipeline zu speichern und 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

Navigieren Sie in der Automation Cloud über die linke Navigationsleiste zu Automation Ops.
Wählen Sie Pipelines aus. Die verfügbaren Pipelines werden angezeigt.
Wählen Sie eine Pipeline und dann Neuen Auftrag startenaus. Dadurch wird die Pipeline ausgeführt, und Sie können den Fortschritt für jeden Schritt in Echtzeit sehen.

Von hier aus können Sie die Pipeline auch bearbeiten, indem Sie Pipeline-Einstellungen auswählen. Dadurch wird die Pipelinezusammenfassung angezeigt, von der aus Sie Folgendes tun können:

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

Die folgenden vordefinierten Pipelineprozesse sind standardmäßig verfügbar:

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 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 den folgenden Satz von Standardargumenten für den Pipeline-Prozess:

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

Protokolle werden für jede Ausführung der Pipeline generiert. Sie können die Protokolle in Automation Ops anzeigen. Da bei jeder Pipelineausführung ein Auftrag im Orchestrator erstellt wird, 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 anzeigenaus.

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:

Wechseln Sie zum Github-Repository und wählen Sie Settings > Webhooks aus.
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:

Wechseln Sie zum Azure DevOps-Repository und wählen Sie Projekteinstellungen > Dienst-Hooks aus.
Wählen Sie auf dem zu löschenden Webhook Bearbeiten aus.
Stellen Sie sicher, dass die Webhook-URL mit /roboticsops_/cicd_/api/webhooks/azure/pipeline endet.
Löschen Sie die Webhook-URL.