Snowflake releases

Snowflake ist bestrebt, seinen Benutzern eine nahtlose, stets aktuelle Nutzungserfahrung zu bieten und gleichzeitig durch schnelle Entwicklung und kontinuierliche Innovation einen immer höheren Wert zu erzielen.

Um dieser Verpflichtung nachzukommen, stellen wir jede Woche neue Releases bereit. Auf diese Weise können wir regelmäßig Leistungsverbesserungen in Form neuer Features, Erweiterungen und Korrekturen bereitstellen. Die Bereitstellungen erfolgen transparent im Hintergrund und führen weder zu Ausfallzeiten noch Betriebsunterbrechungen. So können Benutzer immer sicher sein, dass sie gerade das aktuelle Release verwenden und Zugriff auf die neuesten Features haben.

This topic describes the process we follow for daily and weekly releases, including the option to request 24-hour early access for Enterprise Edition and higher accounts to enable additional release testing (if desired).

Release types (daily and weekly)

Each week, Snowflake deploys two planned full releases:

Daily release:

Deployed only to Early Access accounts.

Weekly release:

Deployed to all customer accounts.

Vollständiges Release:

Ein vollständiges Release kann eines der folgenden Elemente enthalten:

  • Neue Features

  • Erweiterung/Aktualisierung der Features

  • Korrekturen (Fixes)

  • Verhaltensänderungen (siehe nächster Abschnitt unter diesem Thema)

In addition, a full release includes updated Snowflake release notes documentation per weekly release cycle. See Versionshinweise zu Snowflake-Servern und Aktualisierungen von Features.

Patch-Release:

A patch release includes fixes only.

Darüber hinaus werden (je nach Bedarf) während oder nach der Fertigstellung des vollständigen Releases Patch-Releases bereitgestellt, um aufgetretene Probleme zu beheben.

Behavior changes (monthly)

Each month — except for November and December — Snowflake selects one of the weekly full releases for the month to introduce behavior changes. The weekly release selected for the behavior changes may vary, but is typically the 3rd or 4th release for the month.

Eine Verhaltensänderung ist definiert als jede Änderung eines bestehenden Verhaltens, die zu anderen Ergebnissen als zuvor führt und sich auf den Kundencode oder die Workloads auswirken kann. Verhaltensänderungen werden in Bundles bereitgestellt, die die folgende Namenskonventionen verwenden:

YYYY_NN

Dabei steht YYYY für das Jahr und NN für die Ordnungszahl des Releases innerhalb des Jahres. Beispielsweise wäre 2022_06 das 6. Verhaltensänderungs-Bundle, das 2022 eingeführt wurde.

Weitere Details dazu finden Sie unter Verwalten von Verhaltensänderungen.

Bundle lifecycle

Der Lebenszyklus des Verhaltensänderungs-Bundles besteht aus den folgenden beiden Phasen:

Testphase (1. Monat):

Das Bundle wird als „standardmäßig deaktiviert“ eingeführt. Während dieses Zeitraums können Sie das Bundle für ein oder mehrere Konten aktivieren. Normalerweise wählen Sie dafür Konten aus, die für die Entwicklung oder QA (Qualitätssicherung) bestimmt sind, damit Sie die Änderungen testen können, ohne Ihre Produktionskonten zu beeinträchtigen.

Opt-out-Phase (2. Monat):

Das Bundle wird von „standardmäßig deaktiviert“ auf „standardmäßig aktiviert“ umgestellt. Während dieses Zeitraums können Sie das Bundle in Ihren Konten deaktivieren. Auf diese Weise können Sie die Änderungen im Bundle, in der Regel für Produktionskonten, aufschieben und gleichzeitig alle notwendigen Anpassungen vornehmen, um die Auswirkungen der Änderungen zu minimieren.

During these two periods, Snowflake doesn’t override the setting for a given bundle. For example, if you disable a bundle during the testing period, we do not enable it at the beginning of the opt-out period.

Nach Ablauf der Opt-out-Phase aktiviert Snowflake die Verhaltensänderungen im Bundle für alle Konten, sodass dieses Bundle als „allgemein verfügbar“ gilt. Ab diesem Zeitpunkt können Sie das Bundle weder aktivieren noch deaktivieren. Sie können jedoch weiterhin die vorübergehende Deaktivierung einzelner Verhaltensänderungen im Bundle direkt beim Snowflake-Support beantragen.

Behavior change documentation

Ein Release, das Verhaltensänderungs-Bundles enthält, enthält die folgende Dokumentation (zusätzlich zu den Versionshinweisen für das Release):

  • Eine Auflistung der bevorstehenden und der kürzlich implementierten Änderungen des Bundles. Siehe Ankündigungen von Verhaltensänderungen.

  • Eine Beschreibung der einzelnen Verhaltensänderungen. Die Verhaltensänderungen sind auf der Webseite des jeweiligen Bundles aufgeführt.

  • Eine Auflistung der bevorstehenden und kürzlich implementierten Änderungen außerhalb des Bundles. Siehe Verhaltensänderungen außerhalb von Bundles.

Pre-release testing and validation

Bei Snowflake hat die Release-Qualität höchste Priorität. Bevor ein Release Version bereitgestellt wird, durchläuft es einen umfassenden Satz von Validierungstests, die Folgendes umfassen:

  • Normale Build-Tests.

  • Kontinuierliche Workload- und Performancetests.

Darüber hinaus wird vor dem Umstellen von Kundenkonten auf ein neues Release die folgende Validierung durchgeführt:

  • Vollumfängliche Regressionstests in internen Accounts über alle unterstützten Cloudplattformen.

  • Simulieren der Ausführung ausgewählter betroffener Kunden-Workloads (z. B. Abfragen auf Kundendaten), mit Schwerpunkt auf Workloads, die am ehesten von den Änderungen im Release betroffen sind.

Staged release process

After a full release has been deployed, Snowflake doesn’t move all accounts to the release at the same time. Accounts are moved to the release using a multi-stage approach over multiple days. Accounts are moved to the full release in the following order, based on their Snowflake Edition:

Stage 1:

(early access) for designated Enterprise (or higher) accounts.

Stage 2:

(regular access) for Standard accounts.

Stage 3:

(late access) for Enterprise (or higher) accounts.

Stage 4:

(final stable access) for Enterprise (or higher) accounts.

Typically, the minimum amount of time between the early access and final stages is 48 hours, but it may be longer. This staged approach enables Snowflake to monitor activity as accounts are moved and respond to any issues that may occur. It also enables designating Enterprise accounts for early access testing (see the next section in this topic).

Bemerkung

Dieser stufenweise Ansatz gilt nur für vollständige Releases. Bei Patch-Releases werden alle Konten am selben Tag umgestellt.

Wenn bei der Umstellung der Konten auf ein vollständiges Release oder ein Patch-Release Probleme auftreten, wird die Release-Bereitstellung möglicherweise angehalten oder zurückgesetzt. In den meisten Fällen wird eine überarbeitete Version des angehaltenen oder zurückgesetzten Releases innerhalb von 24–48 Stunden bereitgestellt.

Early access to full releases

Wenn Sie über mehrere Enterprise Edition-Konten (oder höher) verfügen, können Sie eines oder mehrere dieser Konten für den Vorabzugriff vorsehen, um den Vorteil des Zeitraums zwischen Vorabzugriff und finalem Zugriff von vollständigen Releases nutzen zu können. Dies kann besonders hilfreich sein, wenn Sie separate Konten für Entwicklung/Test und Produktion verwenden.

Um ein Konto für den Vorabzugriff festzulegen, wenden Sie sich an Ihren Snowflake-Kundenbetreuer.

After you have designated an account for early access, you can implement a testing framework similar to the following:

  1. Verwenden Sie CURRENT_VERSION (oder eine UDF, die ähnliche Ergebnisse zurückgibt), um zu überprüfen, ob das Vorabzugriffskonto auf das vollständige Release umgestellt wurde.

  2. Verwenden Sie Ihre Vorabzugriffskonten, um die Produktions-Workloads mit dem vollständigen Release zu testen.

  3. Sollten Probleme auftreten, benachrichtigen Sie den Snowflake-Support, der mit Ihnen zusammenarbeiten kann, um zu verhindern, dass die Probleme Ihre anderen Konten beeinträchtigen.

Tipp

Ein Vorabzugriff ist für Organisationen mit Enterprise Edition-Konten weder erforderlich noch empfehlenswert. Die strengen Release-Tests und die Überwachung während der Bereitstellung durch Snowflake reichen normalerweise aus, um die meisten Probleme zu vermeiden. Der Vorabzugriff ist in erster Linie für Unternehmen gedacht, die bei Umstellung ihrer Produktionskonten auf vollständige Releases zusätzliche Sicherheit wünschen.