Versions de Snowflake¶

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 12 heures pour les comptes Enterprise Edition et Business Critical Edition, ou un accès anticipé de 24 heures pour des comptes Virtual Private Snowflake (VPS) afin d’activer des tests de versions supplémentaires (si vous le souhaitez).

Dans ce chapitre :

Types de versions (hebdomadaires)
Changements de comportement (mensuel)
- Cycle de vie du bundle
- Documentation sur le changement de comportement
Test/validation préliminaire
Processus de publication par étapes
Accès anticipé aux versions complètes

Types de versions (hebdomadaires)¶

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 Nouveauté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é.

Changements de comportement (mensuel)¶

Chaque mois (à l’exception de novembre et de décembre), Snowflake choisit l’une des versions hebdomadaires complètes du mois pour lancer des changements de comportement. La version hebdomadaire sélectionnée pour les changements de comportement peut varier, mais il s’agit généralement de la 3e ou de la 4e version du mois.

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

Où 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.

Cycle de vie du bundle¶

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.

Pendant ces deux périodes, Snowflake n’annule pas le réglage d’un bundle donné. Par exemple, si vous désactivez un bundle pendant la période de test, nous ne l’activons pas au début de la période d’exclusion.

À 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, vous ne pouvez plus 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.

Documentation sur le changement de comportement¶

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 Journal des modifications 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 Changement de comportement hors bundle.

Test/validation préliminaire¶

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.

Processus de publication par étapes¶

Lorsqu’une version complète a été déployée, Snowflake ne déplace pas tous les comptes vers cette version en même temps. Les comptes sont déplacés en utilisant une approche à trois étapes sur plusieurs jours. Les comptes sont déplacés vers la version complète dans l’ordre suivant, en fonction de leur édition Snowflake :

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 général, le temps minimum entre les étapes d’accès anticipé et d’accès final est de 12 à 24 heures, suivant votre édition Snowflake, mais ce délai peut être plus long ou plus court. 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 correctif, le déploiement peut être interrompu ou annulé. Dans la plupart des cas, le suivi jusqu’à la version à un déploiement interrompu/annulé dure entre 24 et 48 heures.

Accès anticipé aux versions complètes¶

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.

Une fois que vous avez désigné un compte pour un accès anticipé, vous pouvez mettre en œuvre un cadre de test similaire au suivant :

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.
Utilisez vos comptes d’accès anticipé pour tester vos charges de travail de production par rapport à la version complète.
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.