Pipelines und Bereitstellungen Workflow-Version 24.1.2

Verwenden Sie diesen Workflow, wenn Sie Anforderungen für die App-Bereitstellung in App Engine Management Center (AEMC) verwalten, um zu verstehen, wie sich App-Bereitstellungen durch Ihre Pipelines in der im November 2023 veröffentlichten Version 24.1.2 bewegen.

Abbildung : 1. Pipelines und Bereitstellungen – Workflow

In diesem Workflow:

1. Die anfordernde Person wählt Absenden in App Engine Studioaus, wodurch der Haupt-Flow ausgelöst wird.
2. Das System führt im Hintergrund die folgenden Aufgaben aus:
   1. Validiert die Nutzlast.
   2. Ruft das App-Manifest aus dem sys_app- Datensatz in der Quellinstanz ab.
   3. Erstellt eine Bereitstellungsanforderung in der Controller-Instanz.
   4. Sendet eine E-Mail von der Controller-Instanz, um die anfordernde Person zu benachrichtigen, dass die Anforderung erstellt wurde.
   5. Veröffentlicht die Anwendung im App-Repository.
3. Je nachdem, ob während der Veröffentlichung Fehler aufgetreten sind oder nicht, führt das System unterschiedliche Aktionen aus.
   1. Wenn die App-Veröffentlichung Fehler enthält und der Fehlerschweregrad Fehlerist, erstellt das System den aktualisierten Datensatz und wartet auf seine Genehmigung.
   2. Wenn keine Fehler vorliegen oder wenn Fehler vorhanden sind, der Schweregrad des Fehlers jedoch nicht Fehlerist, sucht das System nach der nächsten Umgebung im Pipeline-Datensatz.
      1. Wenn die nächste Umgebung nicht vorhanden ist, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person zu benachrichtigen, dass die Anforderung geschlossen wurde und die App in der Zielinstanz veröffentlicht wurde. Diese Aktion beendet den Workflow.
      2. Wenn die nächste Umgebung vorhanden ist, aktualisiert das System das Feld Zielumgebung in der Bereitstellungsanforderung auf die nächste Umgebung. Dann erstellt das System den aktualisierten Datensatz und wartet auf seine Genehmigung.
4. Je nachdem, ob der neue Datensatz genehmigt wurde, führt das System unterschiedliche Aktionen aus.
   1. Wenn der Datensatz nicht genehmigt wird, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person zu benachrichtigen, dass die Anforderung nicht genehmigt wurde und die Anforderung geschlossen wurde. Diese Aktion beendet den Workflow.
   2. Wenn der Datensatz genehmigt wird und Test als Zielumgebungfestgelegtist, führt das System die folgenden Aktionen aus:
      1. Stellt die App in der Testumgebung bereit, wenn die App dort nicht verfügbar ist.
      2. Führt den Instanzscan der Definitionen bereichsbezogener Apps und alle anderen Suiten in der Tabelle „Scan-Suites“ [[scan_suites]] in der Testinstanz aus.
         Hinweis:

         Die Tabelle „Scan-Suites“ muss in der Controller-Instanz ausgefüllt werden.
      3. Führt die Automated Test Framework-Suite (ATF) für die Anwendungsbereitstellungs-Testsuite und alle Suites in der Tabelle „Scan-Suites“ [scan_suites] in der Testinstanz aus.
      4. Schreibt Instanzscan- und ATF-Testergebnisse in die Tabelle „Ergebnis der Bereitstellungsumgebung“ und in den Aktivitätenstrom der Bereitstellungsanforderung.
      5. Bringt den Workflow zu Schritt 3 zurück, wo nach Fehlern gesucht wird.
   3. Wenn der Datensatz genehmigt wird und die Zielumgebung auf „Produktion“ festgelegtist, beginnt die App den geplanten Bereitstellungsprozess mit der Change-Management-Integration.
      1. Der App Engine-Administrator wählt Genehmigen und Change-Anforderung erstellen aus. Eine Change-Anforderung wird basierend auf der während des geführten Setups ausgewählten Vorlage erstellt.
      2. Je nachdem, ob die App als Configuration Item (CI) registriert ist, führt das System unterschiedliche Aktionen aus.
         1. Wenn die App nicht als CI registriert ist, registriert das System die App als CI und fügt dann das betroffene CI dem Change Request hinzu.
         2. Wenn die App als CI registriert ist, fügt das System der Change-Anforderung das betroffene CI hinzu.
      3. Je nachdem, ob sich die Change-Anforderung im Status Implementieren befindet, führt das System unterschiedliche Aktionen aus.
         1. Wenn der Status der Change-Anforderung nicht „Implementieren“und der Status nicht „Bewerten“ oder „Autorisieren“lautet, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person zu benachrichtigen, dass ihre Anforderung nicht genehmigt und geschlossen wurde. Hiermit wird der Workflow beendet.
         2. Wenn der Status der Change-Anforderung nicht Implementierenlautet und der Status Bewerten oder Autorisierenlautet, wartet das System, bis der Status Implementierenlautet.
         3. Wenn sich die Change-Anforderung im Status Implementieren befindet, erstellt das System eine Change-Aufgabe, um die App-Bereitstellung zu planen.
      4. Wenn der Status der Change-Anforderung „Implementieren“ lautet und das geplante Startdatum nicht „ Jetzt“ oder „In der Vergangenheit“ lautet, wartet das System, bis diese beiden Bedingungen erfüllt sind
      5. Wenn der Status der Change-Anforderung „ Implementieren“ und das geplante Startdatum „Jetzt“ oder in der Vergangenheit ist, die Anforderung jedoch „Abgelehnt“ oder „Abgebrochen“lautet, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person zu benachrichtigen, dass ihre Anforderung nicht genehmigt und geschlossen wurde . Hiermit wird der Workflow beendet.
      6. Wenn der Status der Change-Anforderung „ Implementieren“ und das geplante Startdatum „Jetzt“ oder in der Vergangenheit ist, plant das System die App-Bereitstellung für die Produktion basierend auf dem geplanten Startdatum im Change-Anforderung. Das System schließt die Change-Aufgabe und schließt dann die Bereitstellungsanforderung. Hiermit wird der Workflow beendet.
   4. Wenn der Datensatz genehmigt wird und die Zielumgebung nicht Test oder Produktionist, stellt das System die App in der Zielumgebung bereit, falls sie dort nicht verfügbar ist.

      Der Workflow beginnt von vorne, wenn eine anfordernde Person in App Engine Studio erneut Absenden auswählt.