Développer une nouvelle version d’une application¶

Testez entièrement une application avant de lancer l’analyse de sécurité automatisée¶

Les actions suivantes peuvent déclencher l’analyse de sécurité automatisée :

• Définition de la propriété DISTRIBUTION du paquet d’application sur EXTERNAL si une version de l’application existe

• Ajout d’une nouvelle version ou d’un nouveau correctif sur un paquet d’application dont la propriété DISTRIBUTION est définie sur EXTERNAL

Snowflake vous recommande de tester entièrement une nouvelle version ou un correctif de votre application en local avant de lancer l’analyse de sécurité, afin d’éviter les retards et les itérations multiples de l’analyse en cas de défaillance.

Assurer la compatibilité entre les versions¶

Les fournisseurs doivent s’assurer qu’une nouvelle version est compatible avec la version précédente d’une application. Par exemple, si une application dispose des versions v1 et v2, la v2 doit être compatible avec la v1. Lorsque la version v3 sera ajoutée, elle devra être compatible avec la version v2. Toutefois, comme il ne peut exister que deux versions d’une application à la fois, la version v3 ne doit pas nécessairement être compatible avec la version v1.

Le code exécuté dans la version précédente doit gérer les changements d’état introduits dans la nouvelle version. Pour gérer les objets sans état, les fournisseurs doivent utiliser des schémas à versions afin de s’assurer que les mises à jour sont gérées correctement. Pour plus d’informations, voir Utiliser un schéma versionné pour gérer les objets de l’application entre les différentes versions.

Minimiser les changements d’état dans les correctifs¶

Les fournisseurs doivent s’assurer que les nouveaux correctifs n’introduisent pas de changements d’état différents des correctifs précédents de la même version. Les fournisseurs doivent minimiser les changements d’état tels que l’ajout ou la modification de tables ou de colonnes lorsqu’ils développent un correctif. Les tables et les colonnes doivent rester compatibles avec toutes les versions et tous les correctifs. Les correctifs doivent se concentrer sur la correction de bogues ou l’ajout de fonctions mineures sans impliquer de modifications de l’état.

Les changements d’état ne doivent être effectués que lors de la mise à jour de la version d’une application.

Utiliser des pratiques sûres lorsque vous créez des objets à partir du script d’installation¶

Lorsque vous créez des objets à partir du script de configuration, tenez compte des meilleures pratiques suivantes :

• Utilisez CREATE IF NOT EXISTS :

  Vous devez toujours utiliser CREATE OR REPLACE, CREATE IF NOT EXISTS ou CREATE OR ALTER, selon le cas, pour créer des objets de base de données tels que des tables, des vues, des fonctions ou des procédures. Cela permet d’éviter les erreurs lors de la création d’objets qui existent déjà pendant la mise à niveau.

  Snowflake recommande d’utiliser CREATE OR REPLACE uniquement pour les objets sans état, tels que les fonctions ou les procédures, mais pas pour les objets avec état, tels que les tables.

• Veiller à ce que le script d’installation de chaque application soit autonome

  Chaque version de l’application doit être complète et indépendante. Par exemple, si une table a été créée dans la version v2.0 à l’aide de l’instruction CREATE TABLE IF NOT EXISTS a(int c) et que la version v3.0 inclut ALTER TABLE A(…), assurez-vous que les instructions CREATE TABLE et ALTER TABLE sont présentes dans la version v3.0. Ainsi, les utilisateurs qui installent l’application à partir d’une version ultérieure disposent de tous les schémas et objets nécessaires.

• Utiliser uniquement des changements idempotents dans le script de configuration

  Structurez les instructions CREATE et ALTER de manière à ce qu’elles soient idempotentes et qu’elles puissent être exécutées plusieurs fois sans erreur ni effet secondaire imprévu. Si le script d’installation échoue pendant l’installation, Snowflake réexécute le script d’installation depuis le début. Si un schéma versionné a déjà été créé pour cette version, il n’est ni recréé ni supprimé. C’est pourquoi les fournisseurs doivent utiliser la version CREATE IF NOT EXISTS des commandes CREATE.

  Par exemple :

  • Utilisez ALTER TABLE ADD COLUMN IF NOT EXISTS pour vous assurer que les colonnes ne sont ajoutées que si elles n’existent pas déjà.

  • Lors de l’insertion de lignes, mettez en œuvre des mesures de protection afin d’éviter la duplication des lignes si elle n’est pas intentionnelle, car les mises à niveau peuvent être répétées plusieurs fois.

Soyez prudent lorsque vous créez ou supprimez des rôles d’application¶

Soyez prudent lorsque vous créez ou supprimez des rôles d’application dans une version ou un correctif. Les rôles d’application ne sont pas versionnés. L’abandon d’un rôle d’application ou la révocation d’une autorisation sur un objet d’une version à l’autre peut entraîner l’arrêt du fonctionnement de l’application ou empêcher les consommateurs d’y accéder.

Évitez d’utiliser CREATE OR REPLACE APPLICATION ROLE. Au lieu de cela, utilisez CREATEAPPLICATION ROLE IF NOT EXISTS. La clause OR REPLACE supprimera et recréera des rôles, ce qui entraînera des problèmes d’autorisation, car les rôles de niveau compte accordés au rôle d’application dans les versions précédentes devront être réattribués.

Interrompre l’exécution du script d’installation¶

Pour minimiser les temps d’arrêt et vous assurer que les services sont prêts, utilisez la fonction du système SYSTEM$WAIT_FOR_SERVICES dans le script de configuration après avoir créé ou modifié un service :

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

Cette commande met le script d’installation en pause jusqu’à ce que l’un des événements suivants se produise :

• Tous les services nommés transmis à la fonction système ont le statut READY.

• N’importe lequel des services nommés a le statut FAILED.

• 600 secondes se sont écoulées.

Cette fonction du système garantit que l’installation ou la mise à niveau de l’application attend que le service soit disponible ou qu’une défaillance se produise, ce qui garantit que l’état du service est synchronisé avec la mise à niveau de la version.

Points à prendre en compte lors de la mise à niveau des services¶

Le Snowflake Native App Framework fournit la fonction de rappel de l’initialisateur de version qui permet aux fournisseurs de synchroniser les services de mise à niveau avec le reste de la procédure de mise à niveau.

Lors de la mise à niveau d’une application de base, le script d’installation passe à la nouvelle version de l’application en modifiant les objets d’un schéma versionné. Si une erreur survient lors de la mise à niveau, les objets du schéma versionné reviennent à la version précédente de l’application.

Dans le cas d’une application avec conteneurs, les services qui sont créés ou modifiés en exécutant les commandes CREATE SERVICE ou ALTER SERVICE dans le script d’installation utilisent un fichier de spécification de service pour la nouvelle version.

Comme les services ne sont pas créés dans des schémas à version, un service est mis à niveau dès que la commande CREATE SERVICE ou ALTER SERVICE s’exécute avec succès. En cas d’échec plus tard dans le script d’installation, par exemple, les objets des schémas versionnés sont ramenés à la version précédente, mais les services modifiés sont les services de la nouvelle version.

Utiliser un initialisateur de version pour gérer les mises à niveau des services¶

Le Snowflake Native App Framework fournit un initialisateur de version qui est utilisé pour démarrer ou mettre à niveau des services ou d’autres processus connexes, par exemple des tâches. L’initialisateur de version est une procédure stockée de rappel qui est spécifiée dans le fichier manifeste.

L’initialisateur de version est invoqué dans les contextes suivants :

• Lors de l’installation, l’initialisateur de version est appelé dès que le script d’installation de l’application se termine sans erreur.

• Lors de la mise à niveau, il existe deux scénarios possibles dans lesquels l’initialisateur de version est appelé :

  • Si le script d’installation de la nouvelle version réussit, l’initialisateur de version de la nouvelle version de l’application est appelé.

  • Si le script d’installation ou l’initialisateur de version de la nouvelle version échoue, l’initialisateur de version de la version précédente de l’application est appelé. Cela permet à l’initialisateur de la version précédente d’utiliser ALTER SERVICE pour ramener les services à la version précédente.

Ajouter l’initialisateur de version à une application¶

Pour spécifier la procédure stockée utilisée comme initialisateur de version, ajoutez ce qui suit au fichier manifest.yml :

lifecycle_callback:
  version_initializer: callback.version_init

Dans cet exemple, la propriété version_initializer est définie sur une procédure stockée nommée version_init dans un schéma nommé callback.

Dans le script d’installation, un fournisseur peut définir cette procédure dans un schéma versionné, comme le montre l’exemple suivant :

CREATE OR ALTER VERSIONED SCHEMA callback;

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