Pipelines und Bereitstellungen -Workflow Version 24.1.2

Verwenden Sie beim Verwalten von Anforderungen für die App-Bereitstellung in App Engine Management Center (AEMC) diesen Workflow, um zu verstehen, wie App-Bereitstellungen Ihre Pipelines in Version 24.1.2 durchlaufen, die im November 2023 veröffentlicht wurde.

Abbildung : 1. Workflow von Pipelines und Bereitstellungen

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 für die Controller-Instanz.
   4. Sendet eine E-Mail von der Controller-Instanz, um die anfordernde Person darüber zu informieren, dass die Anforderung erstellt wurde.
   5. Veröffentlicht die Anwendung im App-Repository.
3. Das System führt unterschiedliche Aktionen aus, je nachdem, ob während der Veröffentlichung Fehler aufgetreten sind oder nicht.
   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 Fehlerschweregrad jedoch nicht Fehlerist, sucht das System im Pipeline -Datensatz nach der nächsten Umgebung.
      1. Wenn die nächste Umgebung nicht vorhanden ist, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person darüber zu informieren, dass die Anforderung geschlossen wurde und die App in der Zielinstanz veröffentlicht wurde. Mit dieser Aktion wird der Workflow beendet.
      2. Wenn die nächste Umgebung vorhanden ist, aktualisiert das System das Feld Zielumgebung in der Bereitstellungsanforderung auf die nächste Umgebung. Anschließend erstellt das System den aktualisierten Datensatz und wartet auf seine Genehmigung.
4. Das System führt verschiedene Aktionen aus, je nachdem, ob der neue Datensatz genehmigt wurde.
   1. Wenn der Datensatz nicht genehmigt wird, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person darüber zu informieren, dass ihre Anforderung nicht genehmigt wurde und die Anforderung geschlossen wurde. Mit dieser Aktion wird der Workflow beendet.
   2. Wenn der Datensatz genehmigt wird und die ZielumgebungTestlautet, 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 die Instanz-Scan-Suite für bereichsbezogene App-Definitionen und andere Suiten in der Tabelle „ Scan-Suites “ [scan_suites] auf der Controller-Instanz aus.
      3. Führt die Automated Test Framework -Suite (ATF) der Anwendungsbereitstellungs- Testsuite und alle Suiten in der Tabelle „ Scan-Suites “ [scan_suites] auf der Controller-Instanz aus.
      4. Schreibt Instanzscan- und ATF-Testergebnisse in die Ergebnistabelle der Bereitstellungsumgebung und den Aktivitätenstrom in der Bereitstellungsanforderung.
      5. Gibt den Workflow an Schritt 3 zurück, wo nach Fehlern gesucht wird.
   3. Wenn der Datensatz genehmigt wird und die Zielumgebung „ Produktion“ lautet, beginnt die App den geplanten Bereitstellungsprozess mit der Change Management-Integration.
      1. Der App Engine-Administrator wählt Change-Anforderung genehmigen und erstellenaus. Eine Change-Anforderung wird basierend auf der während des geführten Setups ausgewählten Vorlage erstellt.
      2. Das System führt verschiedene Aktionen aus, je nachdem, ob die App als Configuration Item (CI) registriert ist.
         1. Wenn die App nicht als CI registriert ist, registriert das System die App als CI und fügt dann das betroffene CI der Change-Anforderung hinzu.
         2. Wenn die App als CI registriert ist, fügt das System das betroffene CI der Change-Anforderung hinzu.
      3. Das System führt verschiedene Aktionen aus, je nachdem, ob sich der Change Request im Status Implementieren befindet.
         1. Wenn der Status der Change-Anforderung nicht Implementierenist und der Status nicht Bewerten oder Autorisierenlautet, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person darüber zu informieren, dass ihre Anforderung nicht genehmigt wurde und geschlossen wurde. Dadurch wird der Workflow beendet.
         2. Wenn der Change Request-Status 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 ist oder in der Vergangenheit liegt, wartet das System, bis diese beiden Bedingungen erfüllt sind
      5. Wenn der Status der Change-Anforderung Implementieren lautet und das geplante Startdatum auf Jetzt oder in der Vergangenheit festgelegt ist, die Anforderung jedoch Abgelehnt oder Abgebrochenist, sendet das System eine E-Mail von der Controller-Instanz, um die anfordernde Person darüber zu informieren, dass ihre Anforderung nicht genehmigt wurde und geschlossen wurde . Dadurch wird der Workflow beendet.
      6. Wenn der Status der Change-Anforderung Implementieren lautet und das geplante Startdatum auf Jetzt oder in der Vergangenheit festgelegt ist, plant das System die App-Bereitstellung in der Produktion basierend auf dem geplanten Startdatum in der Change-Anforderung. Das System schließt die Change-Aufgabe und schließt dann die Bereitstellungsanforderung. Dadurch wird der Workflow beendet.
   4. Wenn der Datensatz genehmigt wird und die Zielumgebung nicht Test oder Produktionlautet, stellt das System die App in der Zielumgebung bereit, sofern sie dort nicht verfügbar ist.

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