Découvrez la nouvelle fonctionnalité d’Ibexa DXP v3.3 : le Bundle de Migrations
Un service numérique commence souvent sa vie en tant que projet, mais il prend vraiment vie après son lancement en maintenance continue. Après le lancement initial, le travail se poursuit au fur et à mesure que des fonctionnalités sont ajoutées et des conceptions modifiées. Pendant la phase de pré-lancement, ajouter et modifier des éléments est relativement facile car le système n'est pas encore opérationnel. Une fois live, apporter des changements nécessite plus de discipline, mais cela ne doit pas réduire le rythme de développement. Avec la version Ibexa DXP 3.3, nous ajoutons un outil pour faciliter la gestion des modifications : le Bundle de Migrations Ibexa.
Ibexa DXP dispose d'excellents outils pour gérer les modifications apportées au contenu et aux données, allant du contrôle de version intégré à la corbeille et plus encore. Les développeurs sont habitués depuis longtemps à stocker leur code dans le contrôle de version, ce dernier suivant les modifications apportées. La pratique a été étendue à l'hébergement grâce au concept d'infrastructure en tant que code (IaC); la configuration du service est stockée avec la logique d'application dans le contrôle de version. L'infrastructure nécessaire est déployée automatiquement sur la base de ce plan. C'est ainsi que fonctionne Ibexa Cloud.
Le suivi des modifications de la structure de données peut également être effectué à l'aide du contrôle de version. Les migrations de schéma de base de données impliquent le stockage des modifications apportées aux définitions de base de données sous forme de fichiers pouvant être exécutés dans d'autres environnements pour répliquer les modifications. Ibexa DXP utilise des bases de données relationnelles pour stocker des données brutes, mais l'utilisation de migrations de bases de données pour déplacer les modifications vers le référentiel de contenu n'est pas quelque chose qui est faisable.
C'est là qu'interviennent les Migrations Ibexa. Ce package permet de définir les modifications du référentiel dans les fichiers de configuration. Ceux-ci peuvent être exécutés à n'importe quel endroit et apporteront les modifications à un environnement particulier. Cela permet à un développeur d'ajouter un nouveau champ sur sa machine locale et de générer un fichier défini qui peut être reporté en préparation et finalement en production. Cela réduit le travail manuel et les possibilités d'erreurs humaines.
Un aperçu des migrations en développement
Les migrations sont une fonctionnalité destinée aux développeurs avec laquelle les administrateurs de site ou les visiteurs ne seront jamais directement confontrés. Pour rendre les migrations plus compréhensibles, considérons qu'il s'agit d'un simple ajout de fonctionnalités. Par exemple, il y a un besoin d'ajouter un champ de texte d'introduction aux articles de blog et de l'afficher au-dessus du corps du texte. Sans utiliser les migrations, le développeur devrait soit ajouter le champ manuellement à chaque base de données (production, préparation et développement), soit l'ajouter à la base de données de production et le copier dans les autres environnements. Le développeur devra également synchroniser manuellement le code avec la base de données utilisée.
La copie manuelle des définitions de champ fonctionnera toujours, mais elle est laborieuse et sujette aux fautes de frappe et autres erreurs diverses. Apporter des modifications à la base de données principale et la copier en aval fonctionne, mais présente certains inconvénients : toutes les données seront réinitialisées à partir de la base de données cible, ce qui peut ne pas être acceptable. De plus, il est inutile de transférer toute la masse de données et cela n'est absolument pas faisable pour les grandes bases de données. Et parfois, les modifications ne peuvent pas être intégrées à la production (lors de la création d'un type de champ personnalisé, par exemple). En fin de compte, aucune de ces possibilités n'est idéale.
Avec les migrations, nous pouvons exporter les modifications vers un fichier de migration léger et portable. L'exécution de cette migration appliquera les modifications au référentiel sur place et ensuite, comme si vous le faisiez manuellement via l'interface d'administration. Ce fichier est également stocké avec la version du code, ainsi dans notre exemple le changement de modèle qui afficherait le champ de texte d'introduction. Cela lie à la fois la logique et les changements de données en un seul livrable. Lorsque cette version est déployée, le champ est ajouté et le code est mis à jour.
Un petit coup de main avec les Migrations Ibexa
La fonctionnalité de migration s'exécute complètement comme une application de ligne de commande. Les utilisateurs ont des options pour exécuter, générer et convertir (plus d'informations ci-dessous) des fichiers de migration. Les fichiers eux-mêmes sont en YAML lisible par l'humain et peuvent être créés manuellement avec un éditeur de texte. Le balisage pour ajouter le champ de texte d'introduction au message est indiqué ci-dessous :
- type: content_type mode: update match: field: content_type_identifier value: blog_post metadata: identifier: blog_post fields: - identifier: intro_text type: ezrichtext position: 5 translations: eng-GB: name: Intro text required: true searchable: true infoCollector: false translatable: true
Placé dans le répertoire src / Migrations / Ibexa /, ils peuvent être exécutés avec la console :
$ ./bin/console ibexa:migrations:migrate Please specify migration file: add_intro_to_blog_post.yaml done!
Son ajout au contrôle de version le rend portable et facile à appliquer dans n'importe quel environnement.
Les migrations sont une fonctionnalité d'infrastructure
La version initiale du bundle Migrations avec Ibexa DXP sera compatible avec des emplacements, des types de contenu et du contenu, des métadonnées telles que des états et des sections d'objet ainsi que des utilisateurs et des groupes d'utilisateurs. Cela ne couvre pas tous les cas d'utilisation possibles, mais les plus courants. À l'avenir, nous continuerons d'ajouter plus de fonctionnalités, y compris pour de nouvelles fonctionnalités telles que les segments et l'API de segmentation qui a été introduite dans Ibexa DXP 3.2.
Il convient de noter qu'il existe des packages de migration tiers pour les prédécesseurs d'Ibexa DXP. Maintenant, avec la version 3.3, nous ajoutons une option similaire à notre produit. Avec une option de première partie, nous pouvons assumer l'entière responsabilité de sa maintenance et de son support. Avec une implémentation propre, nous avons une base contemporaine qui nous permettra de prendre en charge rapidement les nouvelles fonctionnalités que nous ajoutons à notre référentiel.
Les clients qui souhaitent passer à Ibexa DXP 3.3 et utilisent déjà une option tierce telle que le Bundle de Migrations Kaliop peuvent convertir les fichiers de migration au format Ibexa Migrations. Les options tierces continueront de fonctionner tant qu'elles seront compatibles avec le logiciel principal, mais elles ne seront pas couvertes par le support produit. La solution recommandée pour les produits de la version Ibexa DXP 3.3 LTS (Ibexa Content, Ibexa Experience et Ibexa Commerce) est la fonctionnalité de migration incluse.
Les migrations sont finalement un utilitaire pour accélérer le développement sans sacrifier la qualité. Vous pouvez les adopter progressivement. Le site ibexa.co, par exemple, a été développé sans aucune solution de migration en place, mais utilisera Ibexa Migrations dans les mois à venir. Restez à l'écoute pour plus d'articles de blog pratiques sur la façon dont Ibexa DXP peut vous aider à gérer la complexité des implémentations de la plateforme d'expérience numérique.
Photo de Richard Lee sur Unsplash