Entwicklungslebenszyklus

Folgen Sie einer UiPath-Automatisierung von der Maschine eines Entwicklers bis zur Produktion, wenn sich der Code in einem Git-Repository eines Drittanbieters befindet. Mit den CLI-Befehlen wird die Release-Pipeline in jeder Phase ausgeführt.

Diese Seite folgt einer UiPath-Automatisierung von der Maschine eines Entwicklers bis zur Produktion, wenn Code, Verlauf und Zusammenarbeit live in einem Git-Repository eines Drittanbieters verwaltet werden. Jeder folgende Schritt entspricht einem nummerierten Vorgang im Diagramm. Jeder Schritt erklärt, was passiert, und wo einer angewendet wird, wird der uip Befehl angezeigt, der ihn ausführt. Platzhalter in $CAPS sind von Ihnen angegebene Werte.

Der richtige Pfad von der Maschine des Entwicklers zur Produktion. Die Leitplanken werden für die Pull-Anforderung ausgeführt, sodass die Hauptverschiebung nur bei einer Zusammenführung erfolgt, die sie bereits bestanden hat und diese Zusammenführung die Release-Pipeline auslöst. Blaue Felder sind Nicht-UiPath-Systeme, orange Felder sind UiPath und grauen Felder sind Runtime-Umgebungen. Gestrichelte Pfeile sind Ereignisse und keine Aktionen einer Person. Wählen Sie das Diagramm aus, um es in voller Größe zu öffnen.

Voraussetzungen

• Ein Source Control-Repository für Ihre Automatisierungsprojekte.
• Ein CI/CD-System (Continuous Integration and Continuous Delivery), das die UiPath CLI ausführen und für die manuelle Genehmigung anhalten kann.
• Separate UiPath-Umgebungen für Entwicklung, Tests und Produktion.
• Anmeldeinformationen, die die Pipeline zur Authentifizierung bei UiPath verwenden kann. Siehe Authentifizierung.

Schritt für Schritt

01. Speichern Sie lokal

Studio schreibt das Projekt auf den Datenträger des Entwicklers. Die Arbeit wird ausgeführt und ist für andere Benutzer nicht sichtbar.

Kein uip -Befehl. Dies ist eine Studio-Aktion.

02. Debuggen für die Entwicklung

Der Entwickler führt das Projekt für den Entwicklungsmandanten aus Studio aus und debuggt es.

Kein uip -Befehl. Der Entwickler arbeitet in Studio.

03. Verzweigung pushen, Pull-Anforderung öffnen

Die Änderung erfolgt in einer Funktionsverzweigung und der Entwickler öffnet eine Pull-Anforderung für main.

Kein uip -Befehl. Dies ist ein Git-Vorgang.

04. Pull-Anforderung löst Validierung aus

Das Öffnen der Pull-Anforderung löst das CI-System automatisch aus. Keiner startet die Ausführung von Hand.

Kein uip -Befehl. Dies ist ein Ereignis im Git-Repository.

05. Rufen Sie den Code ab

Die Validierungsausführung überprüft den Head der Pull-Anforderung.

Kein uip -Befehl. Das CI-System überprüft den Code.

06. Statische Analyse und andere Leitplanken

Workflow-Analyse und Governance-Regeln werden für das Projekt ausgeführt. Ein Verstoß schlägt bei der Ausführung fehl, bevor sich main ändert. Führen Sie bei einer Lösung die Analyse einmal für jedes darin enthaltene Projekt aus.

uip rpa analyze ./my-solution/MyProject \
  --governance-file-path ./governance.json

Siehe UIP-RPA-Analyse.

07. Prüfungen, die bei der Pull-Anforderung gemeldet wurden

Das Ergebnis wird als Statusprüfung für die Pull-Anforderung angezeigt. Durch den Verzweigungsschutz wird die Prüfung blockiert, anstatt zu empfehlen.

Kein uip -Befehl. Das CI-System meldet das Ergebnis an das Git-Repository.

08. Zusammenführung genehmigte PR

Ein Prüfer genehmigt, die Prüfungen bestehen und die Pull-Anforderung wird in main zusammengeführt.

Kein uip -Befehl. Dies ist ein Git-Vorgang.

09. Das Pushen an Haupttrigger löst die Pipeline aus

Der Zusammenführungs-Commit für main löst automatisch die Release-Pipeline aus.

Kein uip -Befehl. Dies ist ein Ereignis im Git-Repository.

10. Rufen Sie den Code ab

Die Release-Ausführung überprüft main beim Zusammenführungs-Commit.

Kein uip -Befehl. Das CI-System überprüft den Code.

11. Bereitstellung in einer Staging-/UAT-Umgebung (User Acceptance Testing).

Die Release-Pipeline verpackt die Lösung, veröffentlicht sie im Staging-/UAT-Mandanten und stellt sie dort bereit. Das Packen erfolgt in diesem Schritt, da die Sequence keinen separaten Buildschritt hat. Vor der Bereitstellung ändert die Pipeline die Bereitstellungskonfiguration, sodass die Lösung bereits im Mandanten vorhandene Ressourcen wiederverwendet, anstatt Duplikate zu erstellen.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"

uip solution pack ./my-solution ./dist \
  --name my-solution --version "$BUILD_VERSION"

uip solution publish "./dist/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.uat.json
uip solution deploy config link ./deploy-config.uat.json "MyConnection" \
  --name "UatCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.uat.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-uat-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.uat.json

Weitere Informationen zum Verknüpfen von deklarierten Ressourcen mit vorhandenen finden Sie unter Wiederverwenden vorhandener Orchestrator-Ressourcen.

12. Führen Sie Tests aus

Die Pipeline führt den Testsatz für die bereitgestellte Lösung in Staging/UAT aus, wartet auf den Abschluss der Ausführung und ruft den Bericht ab. Siehe Ausführen von Tests in einer Pipeline.

uip tm testsets run --test-set-key "$TEST_SET_KEY"
uip tm wait --execution-id "$EXECUTION_ID"
uip tm report get --execution-id "$EXECUTION_ID"

13. Zur Validierung benachrichtigen

Die Pipeline informiert den Geschäftsbenutzer darüber, dass das Release für die Validierung in Staging/UAT bereit ist.

Kein uip -Befehl. Das Genehmigungsgate im CI-System benachrichtigt seine Prüfer von selbst.

14. Geschäftsvalidierung

Der Geschäftsbenutzer getestet die Lösung im Staging-/UAT-Mandanten. Währenddessen pausiert die Pipelineausführung am Genehmigungsgate und fragt nicht nach einer Antwort ab.

Kein uip -Befehl. Dies ist ein menschlicher Schritt.

15. Genehmigung des Geschäftsbenutzers

Der Geschäftsbenutzer genehmigt das Release, wodurch die Pipeline fortgesetzt wird.

Kein uip -Befehl. Der Genehmiger agiert im CI-System, nicht in der Shell.

16. Paket herunterladen

Der UAT-Mandant dient auch als Artefakt-Feed. Nehmen Sie das genaue Paket, das den Test bestanden hat, anstatt es erneut zu packen, aus der Quelle.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"
uip solution packages download my-solution "$BUILD_VERSION" -d ./artifacts/

17. Für die Produktion bereitstellen

Die Pipeline veröffentlicht das Paket im Produktionsmandanten und stellt es mithilfe desselben Bereitstellungskonfigurationsansatzes wie Schritt 11 bereit. Veröffentlichen Sie dieselbe Datei, die Sie in Schritt 16 heruntergeladen haben. Kein zweites Mal packen.

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$PROD_TENANT"

uip solution publish "./artifacts/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.prod.json
uip solution deploy config link ./deploy-config.prod.json "MyConnection" \
  --name "ProdCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.prod.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-prod-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.prod.json

Weitere Informationen zum Verknüpfen von deklarierten Ressourcen mit vorhandenen finden Sie unter Wiederverwenden vorhandener Orchestrator-Ressourcen.

Führen Sie zum Zurücksetzen denselben deploy run Befehl mit --package-version "$PREVIOUS_VERSION" aus.

Siehe auch

• Packen und Veröffentlichen einer Lösung
• Ausführen von Tests in einer Pipeline
• Bereitstellung von CI für Orchestrator
• CI/CD-Rezepte