Aperçu des versions et des mises à jour de l’application¶
Cette rubrique fournit des informations sur le fonctionnement des versions, des correctifs et des mises à niveau dans le Snowflake Native App Framework.
À propos des versions et des correctifs de l’application¶
Le Snowflake Native App Framework permet aux fournisseurs de créer des versions et des correctifs d’une application. Les versions et les correctifs permettent aux fournisseurs de versionner de nouvelles fonctionnalités et des mises à jour pour les consommateurs.
- Version
Contient généralement des mises à jour importantes d’une Snowflake Native App. Les versions introduisent généralement de nouvelles fonctions et des fonctionnalités modifiées pour une application.
- Correctif
Contient généralement de petites mises à jour d’une Snowflake Native App. Contrairement aux versions, les correctifs ne doivent contenir que de petites mises à jour telles que des corrections de sécurité.
Les versions et les correctifs d’une application sont spécifiés dans le paquet d’application.
Prudence
Une activité ne peut avoir que deux versions actives à la fois. Chaque version d’une application peut comporter jusqu’à 130 correctifs.
Pour ajouter une nouvelle version à un paquet d’application qui a actuellement deux versions définies, les fournisseurs doivent supprimer l’une des versions existantes. Pour supprimer une version, un fournisseur doit :
Assurez-vous que tous les consommateurs ont effectué la mise à jour de la version à supprimer.
Retirez la version du paquet d’application.
Créez une nouvelle version.
Mettez l’application à niveau.
Prudence
Bien qu’une application puisse être mise à niveau dans le compte du consommateur, il se peut que la version précédente de l’application contienne encore du code en cours d’exécution. Les fournisseurs ne peuvent pas retirer la version précédente de l’application du paquet d’application tant que tous les codes en cours d’exécution de la version précédente n’ont pas été exécutés. Cela s’applique à toutes les versions installées de l’application sur l’ensemble des comptes consommateurs. Si une seule mise à niveau échoue, les fournisseurs doivent corriger la raison de l’échec de la mise à niveau avant de pouvoir supprimer la version.
Bien qu’un paquet d’application ne puisse contenir que deux versions actives à la fois, une même version peut contenir plusieurs correctifs. Le Snowflake Native App Framework ne permet pas de déposer des correctifs. Lorsqu’un fournisseur ajoute une nouvelle version à un paquet d’application, la nouvelle version se voit automatiquement attribuer le correctif 0 par défaut. Ce comportement n’est pas modifiable.
Lorsqu’un fournisseur ajoute un nouveau correctif à une version, il peut spécifier manuellement l’identificateur du correctif. Si aucun numéro de correctif n’est fourni, Snowflake incrémente automatiquement la version du correctif de 1.
Note
Chaque version et chaque correctif doivent avoir leurs propres versions du script d’installation et des fichiers d’application.
Mise à niveau des versions et des correctifs¶
Lorsqu’un fournisseur publie une nouvelle version d’une application, le Snowflake Native App Framework s’assure que seule la version précédente de l’application est active. Par exemple, si un fournisseur a publié les versions v1 et v2 d’une application, le Snowflake Native App Framework s’assure que seule la v2 est actuellement installée sur le compte d’un consommateur avant de procéder à la mise à niveau vers la v3. Cela exige que toutes les applications installées utilisant la version v1 soient migrées vers la version v2.
Ainsi, le script d’installation de l’application ne doit tenir compte que des différences entre la v2 et la v3. Le script d’installation n’est rétrocompatible qu’avec la version la plus récente de l’application. Si un fournisseur apporte un changement d’état à l’application, par exemple en créant une nouvelle table ou en ajoutant des colonnes à une table, les fournisseurs n’ont plus qu’à s’assurer qu’il n’y a pas de problème de compatibilité entre deux versions.
En revanche, lorsqu’un fournisseur crée un nouveau correctif pour une version d’une application, le Snowflake Native App Framework n’impose aucune restriction quant au nombre de correctifs actifs en cours d’exécution. Les fournisseurs doivent éviter de modifier l’état d’une application dans un correctif afin d’éviter toute incompatibilité entre plusieurs correctifs.
Objets avec ou sans état¶
Lorsqu’ils développent une nouvelle version d’une application, les fournisseurs doivent se demander si les composants qu’ils modifient doivent préserver leur état d’une version ou d’un correctif à l’autre. Une application typique contient deux types de conteneurs :
- Objets sans état
Les objets sans état sont recréés pour chaque nouvelle version ou correctif de l’application. Les objets sans état ne doivent être disponibles que pour la durée de vie de la version et peuvent être recréés si nécessaire. Les objets sans état sont généralement le code de l’application, y compris les procédures stockées, les fonctions définies par l’utilisateur, les applications Streamlit et tout autre contenu similaire.
Les objets sans état doivent être créés dans un schéma versionné.
- Objets avec état
Les objets avec état sont partagés d’une version ou d’un correctif de l’application à l’autre. Les composants avec état sont destinés à avoir une durée de vie à travers plusieurs versions de l’application. Par exemple, si une application utilise une table pour stocker les informations de configuration dans le compte du consommateur, le contenu de cette table devra être préservé lors de la mise à niveau.
Les objets sans état doivent être créés à l’aide d’un schéma régulier.
À propos des schémas en version¶
Lors de la rédaction du script d’installation de la nouvelle version de l’application, les fournisseurs doivent tenir compte des composants avec et sans état. Pour gérer les objets sans état, le Snowflake Native App Framework fournit un type spécial de schéma de base de données, appelé schéma versionné. Un schéma versionné est similaire à un schéma de base de données classique, avec des fonctionnalités supplémentaires permettant de gérer plusieurs versions d’objets créés par différentes versions d’applications.
Pour plus d’informations, voir Utiliser un schéma versionné pour gérer les objets de l’application entre les différentes versions.
À propos des mises à niveau de l’application¶
Le Snowflake Native App Framework permet aux fournisseurs de mettre à niveau une application vers une nouvelle version ou un nouveau correctif. Pour savoir comment les mises à niveau s’intègrent dans le processus global de développement d’une nouvelle version ou d’un correctif d’une application, consultez le Processus de mise à jour d’une application.
Les fournisseurs peuvent lancer la mise à niveau d’une application vers une nouvelle version ou un nouveau paquet d’application en paramétrant une directive de version sur le paquet d’application. Lorsque la directive de version est modifiée, Snowflake met automatiquement à niveau toutes les instances installées de la version actuelle de l’application vers la version spécifiée par la directive de version.
Lorsque le fournisseur lance une mise à niveau, Snowflake ajoute chaque application à mettre à niveau à une file d’attente. Chaque application est mise à jour au fur et à mesure de la disponibilité des ressources. Le processus de mise à niveau peut prendre un certain temps pour s’achever sur l’ensemble des versions installées de l’application. Pour accélérer le processus de mise à niveau, les consommateurs peuvent également lancer manuellement la mise à niveau d’une application lorsqu’une nouvelle version ou un correctif est disponible.
Note
Après le début du processus de mise à niveau de leur application, les consommateurs ne peuvent plus mettre à jour manuellement l’application.
Pour plus d’informations, voir Mettre à jour une application.
Mises à niveau dans les régions¶
Consultez la rubrique Mise à niveau d’une application dans plusieurs régions pour obtenir des informations sur la mise à niveau d’une application installée dans plusieurs régions à l’aide de l’exécution automatique inter-Cloud.
Cycle de vie de la version et des correctifs de l’application¶
Pour comprendre comment les versions et les correctifs des applications fonctionnent ensemble, considérez un scénario dans lequel un fournisseur a publié une version initiale, v1, d’une application et le consommateur A et le consommateur B ont installé cette version de l’application dans leurs comptes.
Ce scénario est présenté dans les sections suivantes.
La version v1.0 est installée sur le compte du consommateur¶
La figure 1 montre la version v1.0 d’une application qu’un fournisseur a publiée et que deux consommateurs ont installée sur leur compte :
Figure 1 - version v1.0¶
Cette figure montre ce qui suit :
Les fichiers d’application de
v1.0sont mis en zone de préparation.La directive de version du paquet d’application est définie sur
v1.0.Les consommateurs ont installé
v1.0sur leur compte.Le fournisseur a commencé le développement de la version v2.0 dans son compte.
Ajouter la version v2.0 au paquet d’application¶
La figure 2 montre que le fournisseur a téléchargé la version v2.0 et créé une nouvelle version dans le paquet d’application :
Figure 2 - télécharger des fichiers dans la zone de préparation¶
Cette figure présente les éléments suivants :
Après avoir testé la version
v2.0de l’application localement, le fournisseur télécharge le fichierv2.0sur la zone de préparationLe fournisseur crée une nouvelle version de l’application dans le paquet d’application.
La directive de version continue de pointer vers la version
v1.0de l’application.Les consommateurs continuent d’avoir la version
v1.0installée sur leur compte.
Mise à niveau de l’application de la version v1.0 à la version v2.0¶
Pour effectuer une mise à niveau de la version v1.0 à la version v2.0 de l’application, le fournisseur définit la directive de version du paquet d’application sur la version v2.0. Cela lance le processus de mise à niveau de l’application dans les comptes des consommateurs.
Une fois la mise à niveau terminée, les consommateurs A et B ont tous deux la version v2.0 installée sur leur compte, comme le montre le diagramme de la Figure 3.
Figure 3 - passage de la version v1.0 à la version v2.0¶
De plus, dans ce scénario, le fournisseur a commencé à développer et à tester la version v3.0 dans son environnement de développement local.
Abandonner la version v1.0 pour pouvoir créer la v3.0¶
Une fois la mise en zone de préparation terminée, le fournisseur télécharge la version v3.0 sur la zone de préparation. Lorsque le fournisseur souhaite commencer la mise à niveau vers la version v3.0, il doit d’abord s’assurer que tous les consommateurs ont quitté la version v1.0.
Dans le scénario présenté dans la section précédente, tous les consommateurs sont actuellement sur v2.0.
Le fournisseur doit supprimer la version v1.0 du paquet d’application, comme le montre la figure 4 :
Figure 4 - détruirer la version v1.0 du paquet d’application¶
Ajouter la version v3.0 au paquet d’application¶
Après avoir détruit la version v1.0, le fournisseur peut ajouter la version v3.0 au paquet d’application. Dans ce contexte, la directive de version pointe toujours vers v2.0 et les consommateurs ont installé v2.0 sur leur compte.
Figure 5 - ajouter la version v3.0 au paquet d’application¶
Passer à la version v3.0¶
Pour passer à v3.0, le fournisseur met à jour la directive de version pour qu’elle pointe vers v3.0. La mise à niveau commence. Lorsque la mise à niveau est terminée, les consommateurs sont mis à niveau vers la version v3.0, comme le montre la figure suivante :
Figure 5 - passage à la version v3.0¶