Dans quel ordre importer la configuration et mettre à jour les modules?
Étant donné que la version de schéma des modules est stockée dans le stockage de valeurs-clés, elle est unique pour chaque site et n'est pas synchronisée via la gestion de la configuration. Cela a du sens, car les mises à jour peuvent nécessiter des ajustements qui ne sont pas encapsulés dans la configuration (telles que les mises à jour de la base de données), mais il existe d'autres modifications qui peuvent également être incluses dans la configuration (par exemple, ajouter une nouvelle valeur de configuration).
- Y a-t-il des risques à exécuter l'importation de configuration et les mises à jour de base de données dans l'un ou l'autre ordre?
- Quel est l'ordre préféré pour exécuter ces opérations?
- Les crochets de mise à jour doivent-ils faire des aménagements spéciaux pour les éléments de configuration qui ont peut-être déjà été importés?
- Y a-t-il d'autres opérations qui peuvent être nécessaires pour mettre à jour complètement l'environnement de production?
Les mises à jour doivent être exécutées avant l'importation de la configuration
Un problème en attente contre le noyau assurez-vous que les versions de code et de schéma correspondent avant d'autoriser l'importation de la configuration .
Problèmes avec l'importation de config avant les mises à jour
Un hook de mise à jour reposant sur une valeur de configuration peut aboutir à un résultat différent de celui s'il était exécuté sur la valeur de pré-importation.
Une mise à jour peut potentiellement échouer si elle essaie de créer des entités de configuration qui existent déjà.
Préoccupations pour l'importation de config après les mises à jour
Si une mise à jour qui introduit une nouvelle entité de configuration est exécutée en premier, elle créera un nouvel élément de configuration qui aura un UUID différent de celui qui est dans la configuration. Cependant, une fois la configuration importée, l'entité doit être remplacée par la version de configuration.
Il pourrait y avoir un problème potentiel si le remplacement de l'entité affectait le contenu associé. Par exemple, si une mise à jour migre le contenu d'un champ vers un autre, lors de l'importation de la configuration, le champ sera complètement remplacé et le contenu potentiellement perdu. Dans ce cas, le processus de déploiement peut devoir être ajusté pour exécuter les mises à jour sur l'environnement cible et exporter la configuration résultante.