Snowflake releases

Snowflake s’engage à fournir une expérience sans faille et toujours à jour à nos utilisateurs, tout en offrant une valeur toujours croissante grâce à un développement rapide et à une innovation continue.

Pour respecter cet engagement, nous déployons chaque semaine de nouvelles versions. Cela nous permet de proposer régulièrement des améliorations de service sous la forme de nouvelles fonctionnalités, d’améliorations et de correctifs. Les déploiements se déroulent de manière transparente en arrière-plan ; les utilisateurs ne subissent aucun temps d’arrêt ni aucune interruption de service et sont toujours assurés de disposer de la version la plus récente avec un accès aux dernières fonctionnalités.

Ce chapitre décrit le processus que nous suivons pour les versions hebdomadaires, y compris la possibilité de demander un accès anticipé de 24 heures pour les comptes Enterprise Edition et versions ultérieures afin d’activer des tests de versions supplémentaires (si vous le souhaitez).

Release types (weekly)

Chaque semaine, Snowflake déploie deux versions prévues/planifiées :

Version complète:

Une version complète peut comprendre l’un des éléments suivants :

  • Nouvelles fonctionnalités

  • Améliorations ou mises à jour des fonctionnalités

  • Corrections

  • Changements de comportement (voir la section suivante dans cette rubrique)

En outre, une version complète comprend la mise à jour de la documentation des notes de version de Snowflake par cycle hebdomadaire. Voir Notes de version du serveur Snowflake et mises à jour de fonctionnalités..

Les versions complètes peuvent être déployées n’importe quel jour de la semaine, mais nous ne prévoyons généralement pas de versions complètes le vendredi afin de nous prémunir contre les problèmes qui peuvent être rencontrés en dehors des heures de travail.

Version de correctif:

Une version de correctif comprend uniquement des correctifs. Notez que la version de correctif planifiée pour une semaine donnée peut être annulée si la version complète pour la semaine est suffisamment retardée ou prolongée.

En outre, des versions de correctifs sont déployées (selon les besoins) pendant ou après l’achèvement de la version complète afin de résoudre tout problème rencontré.

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.

Un changement de comportement est défini comme toute modification d’un comportement existant qui donne des résultats différents de ceux obtenus auparavant et qui peut avoir un impact sur le code ou les charges de travail du client. Les changements de comportement sont fournis dans des bundles qui utilisent la convention de dénomination suivante :

YYYY_NN

YYYY est l’année et NN est le numéro ordinal de la version au cours de l’année. Par exemple, 2022_06 serait le 6e bundle de changements de comportement lancé en 2022.

Pour plus de détails, voir Gestion des changements de comportement.

Bundle lifecycle

Le cycle de vie du bundle pour le changement de comportement comprend les deux périodes suivantes :

Période d’essai (1er mois):

Le bundle est lancé « désactivé par défaut ». Pendant cette période, vous pouvez choisir d”activer le bundle dans un ou plusieurs comptes. En général, vous choisirez des comptes désignés pour le développement ou le QA (assurance qualité) afin de pouvoir tester les changements sans avoir d’impact sur vos comptes de production.

Période d’exclusion (2e mois):

Le bundle passe de « Désactivé par défaut » à « Activé par défaut ». Pendant cette période, vous pouvez choisir de désactiver le bundle dans vos comptes. Cela vous permet de reporter les changements dans le bundle, généralement pour les comptes de production, tout en effectuant les ajustements nécessaires pour atténuer l’impact des changements.

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.

À la fin de la période d’exclusion, Snowflake active les changements de comportement dans le bundle sur tous les comptes ; à ce moment-là, le bundle est considéré comme « généralement activé ». À partir de ce moment-là, vous ne pouvez pas activer ou désactiver le bundle. Cependant, vous pouvez toujours demander à désactiver temporairement des changements de comportement individuels dans le bundle en contactant l”Assistance de Snowflake.

Behavior change documentation

Une version qui contient des bundles de modifications du comportement comprend la documentation suivante (en plus des Notes de version de la version) :

  • Une liste des changements en bundle à venir et de ceux qui ont été récemment mis en œuvre. Voir Annonces de changement de comportement.

  • Une description de chaque changement de comportement. Les changements de comportement sont listés sur la page de renvoi de chaque bundle.

  • Une liste des changements à venir et des changements récemment mis en œuvre hors bundle. Voir Unbundled behavior changes.

Pre-release testing and validation

Chez Snowflake, la qualité des versions est une priorité absolue. Avant le déploiement de chaque version, elle passe par une suite complète de tests de validation qui incluent :

  • Des tests de compilation réguliers.

  • Des tests continus de charge de travail et de performances.

En outre, avant de déplacer des comptes clients vers une version, la validation suivante est effectuée :

  • Série complète de tests de régression dans les comptes internes sur toutes les plates-formes Cloud prises en charge.

  • Simulation de l’exécution de charges de travail client sélectionnées et impactées (par exemple, des requêtes sur des données client), en se concentrant sur les charges de travail les plus susceptibles d’être impactées par les changements présents dans la version.

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 three-stage approach over multiple days. Accounts are moved to the full release in the following order, based on their Snowflake Edition:

Jour 1:

Étape 1 (accès précoce) pour les comptes Standard et les comptes désignés Enterprise (ou édition supérieure).

Jour 1 ou 2:

Étape 2 (accès régulier) pour les comptes Standard.

Jour 2:

Étape 3 (finale) pour les comptes Enterprise (ou supérieurs).

En règle générale, le délai minimum entre la phase d’accès anticipé et les zones de préparation finales est de 24 heures, mais il peut être plus court ou plus long. Cette approche par étapes permet à Snowflake de surveiller l’activité à mesure que les comptes sont déplacés et de répondre à tous les problèmes qui peuvent survenir. Elle permet également de désigner des comptes Entreprise pour les tests d’accès anticipé (voir la section suivante de ce chapitre).

Note

Cette approche par étapes s’applique uniquement aux versions complètes. Pour les versions de correctifs, tous les comptes sont déplacés le même jour.

En outre, si des problèmes sont découverts lors du déplacement des comptes vers une version complète ou une version de correctifs, le déploiement peut être interrompu ou annulé. Dans la plupart des cas, le suivi d’un déploiement interrompu ou annulé est effectué dans les 24 à 48 heures.

Early access to full releases

Si vous avez plusieurs comptes Enterprise Edition (ou supérieur), vous pouvez désigner un ou plusieurs de ces comptes comme accès anticipé pour bénéficier de la période entre les étapes d’accès anticipé et final pour les versions complètes. Cela peut être particulièrement utile si vous gérez des comptes distincts pour le développement/test et la production.

Pour désigner un compte bénéficiant d’un accès anticipé, veuillez contacter votre représentant de compte Snowflake.

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

  1. Utilisez CURRENT_VERSION (ou une UDF qui renvoie des résultats similaires) pour vérifier quand vos comptes d’accès anticipé disposent bien de la version complète.

  2. Utilisez vos comptes d’accès anticipé pour tester vos charges de travail de production par rapport à la version complète.

  3. En cas de problème, informez le support Snowflake, qui peut travailler avec vous pour éviter que les problèmes ne perturbent vos autres comptes.

Astuce

L’accès anticipé n’est ni requis ni recommandé pour toutes les organisations disposant de comptes Enterprise Edition. Les tests rigoureux des versions et la surveillance de Snowflake pendant les déploiements sont généralement suffisants pour éviter la plupart des problèmes. L’accès anticipé est principalement destiné aux organisations qui souhaitent avoir la certitude que leurs comptes de production ne seront pas affectés par les versions complètes.