Neue Version einer App entwickeln¶

Testen Sie eine App vollständig, bevor Sie den automatischen Sicherheitsscan einleiten¶

Die folgenden Aktionen können den automatischen Sicherheitsscan auslösen:

• Einstellen der Eigenschaft DISTRIBUTION des Anwendungspakets auf EXTERNAL, wenn eine Version der Anwendung existiert

• Hinzufügen einer neuen Version oder eines neuen Patches zu einem Anwendungspaket, bei dem die Eigenschaft DISTRIBUTION auf EXTERNAL gesetzt ist

Snowflake empfiehlt, dass Sie eine neue Version oder einen neuen Patch Ihrer Anwendung vollständig lokal testen, bevor Sie den Sicherheitsscan einleiten, um Verzögerungen und mehrfache Wiederholungen des Scans im Falle eines Fehlers zu vermeiden.

Sicherstellen der Kompatibilität zwischen Versionen¶

Anbieter müssen sicherstellen, dass eine neue Version mit der vorherigen Version einer App kompatibel ist. Wenn es zum Beispiel für eine App die Versionen v1 und v2 gibt, muss v2 mit v1 kompatibel sein. Wenn die Version v3 hinzugefügt wird, muss sie mit der Version v2 kompatibel sein. Da jedoch nur zwei Versionen einer App gleichzeitig existieren können, muss die Version v3 nicht mit der Version v1 kompatibel sein.

Code, der in der Vorgängerversion ausgeführt, muss mit Statusänderungen umgehen können, die in der neuen Version eingeführt wurden. Um zustandslose Objekte zu handhaben, sollten Anbieter versionierte Schemas verwenden, um sicherzustellen, dass Upgrades korrekt gehandhabt werden. Weitere Informationen dazu finden Sie unter Verwenden Sie ein versioniertes Schema, um App-Objekte versionsübergreifend zu verwalten.

Minimieren von Zustandsänderungen in Patches¶

Anbieter müssen sicherstellen, dass neue Patches keine Zustandsänderungen einführen, die sich von früheren Patches der gleichen Version unterscheiden. Anbieter müssen Statusänderungen wie das Hinzufügen oder Ändern von Tabellen oder Spalten bei der Entwicklung eines Patches auf ein Minimum beschränken. Tabellen und Spalten müssen über alle Versionen und Patches hinweg kompatibel bleiben. Patches sollten sich auf die Behebung von Fehlern oder das Hinzufügen kleinerer Features konzentrieren und keine Änderungen am Status beinhalten.

Zustandsänderungen sollten nur bei der Aktualisierung der Version einer App vorgenommen werden.

Wenden Sie sichere Methoden an, wenn Sie Objekte mit dem Setup-Skript erstellen¶

Beachten Sie bei der Erstellung von Objekten aus dem Setup-Skript die folgenden Best Practices:

• Verwenden Sie CREATE IF NOT EXISTS:

  Sie sollten immer CREATE OR REPLACE, CREATE IF NOT EXISTS oder CREATE OR ALTER verwenden, je nachdem, was zutreffend ist, wenn Sie Datenbankobjekte wie Tabellen, Ansichten, Funktionen oder Prozeduren erstellen. Dies verhindert Fehler, wenn Sie versuchen, Objekte zu erstellen, die während des Upgrades bereits existieren.

  Snowflake empfiehlt die Verwendung von CREATE OR REPLACE nur für zustandslose Objekte, wie Funktionen oder Prozeduren, nicht aber für zustandsabhängige Objekte, wie z. B. Tabellen.

• Stellen Sie sicher, dass das Setup-Skript jeder Anwendung in sich geschlossen ist

  Jede Version der App muss vollständig und unabhängig sein. Wenn beispielsweise eine Tabelle in Version v2.0 mit der Anweisung CREATE TABLE IF NOT EXISTS a(int c) erstellt wurde und Version v3.0 ALTER TABLE A(…) enthält, stellen Sie sicher, dass sowohl die CREATE TABLE- als auch die ALTER TABLE-Anweisung in Version v3.0 vorhanden sind. Dadurch wird sichergestellt, dass Benutzer, die die App von einer späteren Version aus installieren, über alle erforderlichen Schemas und Objekte verfügen.

• Verwenden Sie nur idempotente Änderungen im Setup-Skript

  Strukturieren Sie die CREATE und ALTER-Anweisungen so, dass sie idempotent sind, sodass sie mehrfach ohne Fehler oder unbeabsichtigte Nebeneffekte ausgeführt werden können. Wenn das Setup-Skript während der Installation fehlschlägt, führt Snowflake das Setup-Skript noch einmal von vorne aus. Wenn ein versioniertes Schema bereits für diese Version erstellt wurde, wird es nicht neu erstellt oder gelöscht. Aus diesem Grund sollten Anbieter die CREATE IF NOT EXISTS-Version der CREATE-Befehle verwenden.

  Beispiel:

  • Verwenden Sie ALTER TABLE ADD COLUMN IF NOT EXISTS, um sicherzustellen, dass Spalten nur hinzugefügt werden, wenn sie noch nicht vorhanden sind.

  • Setzen Sie beim Einfügen von Zeilen Schutzmaßnahmen ein, um doppelte Zeilen zu verhindern, falls dies nicht beabsichtigt ist, da Upgrades möglicherweise mehrfach wiederholt werden.

Seien Sie vorsichtig beim Erstellen oder Löschen von Anwendungsrollen¶

Seien Sie vorsichtig, wenn Sie Anwendungsrollen in einer Version oder einem Patch erstellen oder löschen. Anwendungsrollen sind nicht versioniert. Wenn Sie eine Anwendungsrolle löschen oder eine Berechtigung für ein Objekt von einer Version auf eine andere widerrufen, kann dies dazu führen, dass die Anwendung nicht mehr funktioniert oder Verbraucher nicht mehr auf die Anwendung zugreifen können.

Vermeiden Sie die Verwendung von CREATE OR REPLACE APPLICATION ROLE. Verwenden Sie stattdessen CREATEAPPLICATION ROLE IF NOT EXISTS. Mit der OR REPLACE-Klausel werden Rollen gelöscht und neu erstellt, was zu Problemen mit den Berechtigungen führt, da Rollen auf Kontoebene, die der Anwendungsrolle in früheren Versionen zugewiesen waren, erneut zugewiesen werden müssen.

Ausführung des Setup-Skripts anhalten¶

Um Ausfallzeiten zu minimieren und sicherzustellen, dass die Dienste einsatzbereit sind, verwenden Sie die Systemfunktion SYSTEM$WAIT_FOR_SERVICES im Setup-Skript, nachdem Sie einen Dienst erstellt oder geändert haben:

SELECT SYSTEM$WAIT_FOR_SERVICES(600, 'services.web_ui', 'services.worker', 'services.aggregation');

Dieser Befehl veranlasst das Setup-Skript so lange zu pausieren, bis einer der folgenden Fälle eintritt:

• Alle benannten Dienste, die an die Systemfunktion übergeben werden, haben den Status READY.

• Einer der genannten Dienste hat den Status FAILED.

• 600 Sekunden sind vergangen.

Diese Systemfunktion stellt sicher, dass die Installation oder Aktualisierung der App erst dann erfolgt, wenn der Dienst verfügbar ist oder ein Fehler auftritt, und gewährleistet so, dass der Dienststatus mit der Versionsaktualisierung übereinstimmt.

Hinweise zum Upgrade von Diensten¶

Das Snowflake Native App Framework bietet eine Callback-Funktion für den Versionsinitialisierer, die es Anbietern ermöglicht, die Aktualisierung von Diensten mit dem Rest des Upgrade-Vorgangs zu synchronisieren.

Während des Upgrades einer Basis-App wird das Setup-Skript auf die neue Version der App aktualisiert, indem Objekte innerhalb eines versionierten Schemas geändert werden. Wenn während des Upgrades ein Fehler auftritt, werden die Objekte im versionierten Schema auf die vorherige Version der App zurückgesetzt.

Im Falle einer App mit Containern verwenden Dienste, die durch die Ausführung der Befehle CREATE SERVICE oder ALTER SERVICE im Setup-Skript erstellt oder geändert werden, eine Dienstspezifikationsdatei für die neue Version.

Da Dienste nicht innerhalb von versionierten Schemas erstellt werden, wird ein Dienst aktualisiert, sobald der Befehl CREATE SERVICE oder ALTER SERVICE erfolgreich ausgeführt wurde. Wenn später im Setup-Skript ein Fehler auftritt, werden beispielsweise die Objekte in versionierten Schemas auf die vorherige Version zurückgesetzt, aber die geänderten Dienste sind die der neuen Version.

Verwenden eines Versionsinitialisierers zur Verwaltung von Dienst-Upgrades¶

Das Snowflake Native App Framework bietet einen Versionsinitialisierer, der zum Starten oder Aktualisieren von Diensten oder anderen verwandten Prozessen, z. B. Aufgaben, verwendet wird. Der Versionsinitialisierer ist eine gespeicherte Callback-Prozedur, die in der Manifest-Datei angegeben wird.

Der Versionsinitialisierer wird in den folgenden Kontexten aufgerufen:

• Während der Installation wird der Versionsinitialisierer aufgerufen, sobald das Setup-Skript der App ohne Fehler abgeschlossen wurde.

• Beim Upgrade gibt es zwei mögliche Szenarios, in denen der Versionsinitialisierer aufgerufen wird:

  • Wenn das Setup-Skript der neuen Version erfolgreich ist, wird der Versionsinitialisierer der neuen Version der App aufgerufen.

  • Wenn das Setup-Skript oder der Versionsinitialisierer der neuen Version fehlschlägt, wird der Versionsinitialisierer der vorherigen Version der App aufgerufen. Dies ermöglicht es dem Versionsinitialisierer der vorherigen Version, den ALTER SERVICE-Befehl zu verwenden, um die Dienste auf die vorherige Version zurückzusetzen.

Versionsinitialisierer zu einer App hinzufügen¶

Um die gespeicherte Prozedur anzugeben, die als Versionsinitialisierer verwendet wird, fügen Sie Folgendes zur Datei manifest.yml hinzu:

lifecycle_callback:
  version_initializer: callback.version_init

In diesem Beispiel wird die Eigenschaft version_initializer auf eine gespeicherte Prozedur namens version_init in einem Schema namens callback gesetzt.

Innerhalb des Setup-Skripts kann ein Anbieter diese Prozedur innerhalb eines versionierten Schemas definieren, wie im folgenden Beispiel gezeigt:

CREATE OR ALTER VERSIONED SCHEMA callback;

CREATE OR REPLACE PROCEDURE callback.version_init()
  ...
  -- body of the version_init() procedure
  ...