CMS en tant que code

Dans Infrastructure as Code: From the Iron Age to the Cloud Age, Kief Morris décrit « l’âge du fer » comme une époque où la croissance de l’infrastructure était limitée par le cycle d’achat du matériel. Étant donné que l’arrivée d’un nouveau serveur pouvait prendre des semaines, il n’y avait pas beaucoup de pression pour installer et configurer rapidement un système d’exploitation sur celui-ci. »

Mais maintenant, à « l’ère du cloud », les systèmes sont déployés à l’aide de services cloud. Bon nombre de ces services, y compris Contentful, fournissent des interfaces utilisateur conviviales où les utilisateurs peuvent configurer des environnements. Malheureusement, à mesure que le nombre de services exploités par les équipes augmente, il devient ingérable de maintenir chacun d’entre eux en pointant et en cliquant sur l’interface utilisateur. « L’infrastructure en tant que code » est une approche qui permet de traiter ce problème : la configuration de chaque service est automatisée et la configuration est stockée avec le code source de l’application dans le contrôle de version.

Les plateformes CMS monolithiques couramment utilisées aujourd’hui ne conviennent pas aux équipes qui appliquent des pratiques de développement agile telles que l’infrastructure en tant que code et la livraison continue. L’approvisionnement, la migration et le test de ces plateformes sont intrinsèquement difficiles à automatiser.

Contentful, en revanche, est une plateforme de contenu composable conçue pour l’ère du cloud.

À l’âge du fer, le développement logiciel reposait sur l’idée de logiciels sous boîte, avec de nouvelles versions publiées une fois par an, voire moins. Les processus de publication, coûteux et chronophages, étaient monnaie courante, avec une approche consistant à tout construire, puis tout tester et enfin tout publier.

À l’ère du cloud, les équipes agiles publient fréquemment, souvent plusieurs fois par semaine, de sorte que des processus de publication coûteux et chronophages ne peuvent pas être utilisés sans paralyser les déploiements. Pour cette raison, de nombreuses équipes agiles ont adopté la livraison continue.

Les équipes qui utilisent la livraison continue disposent d’un pipeline de déploiement, un ensemble de validations par lequel une nouvelle version de logiciel doit passer pour être mise en production. Le pipeline comporte différentes étapes, chacune ayant son propre environnement pour exécuter le logiciel.

Première étape : le développement

Cela se produit souvent sur les ordinateurs personnels des développeurs, où ils créent de nouvelles versions du logiciel. Lorsque les développeurs souhaitent déployer une nouvelle version, ils valident leur dernier code dans un système de contrôle de version et le transfèrent dans un dépôt de code partagé. Cela initie le pipeline.

Deuxième étape : la compilation (ou build)

Cette étape dépend d’un script de compilation capable de créer la version en cours d’exécution du logiciel à partir du code source, d’effectuer des étapes telles que l’installation de dépendances, la compilation ou la transpilation du code et la vérification que le script de compilation s’exécute correctement.

Troisième étape : le test

Cette étape dépend de la disponibilité de tests automatisés permettant de vérifier que le logiciel fonctionne comme prévu et que les nouvelles versions n’ont pas altéré les fonctionnalités qui fonctionnaient dans les versions précédentes.

Quatrième étape : l’assurance qualité

Les développeurs et les responsables de l’assurance qualité utilisent le logiciel et effectuent d’autres tests, en s’assurant que les critères d’acceptation des modifications les plus récentes ont été respectés et que le logiciel est prêt pour la production.

Cinquième étape : le déploiement

Le logiciel est téléchargé sur les serveurs de production. La nouvelle version est maintenant en ligne.

Les équipes qui utilisent Contentful peuvent provisionner des environnements, migrer du contenu et écrire des tests via des API. Cela permet d’intégrer la gestion de contenu dans des pratiques de développement agiles telles que l’infrastructure en tant que code et la livraison continue, afin que les équipes de développement logiciel puissent créer des applications de haute qualité et les déployer rapidement.

Bien que l’adoption de la livraison continue puisse nécessiter un investissement initial et un changement dans la culture de l’équipe, les avantages commerciaux à long terme l’emportent sur les difficultés associées :

Une mise sur le marché plus rapide : la livraison continue facilite et encourage des cycles de livraison plus courts.

Amélioration des pratiques d’ingénierie : lorsque l’entreprise exige des cycles de publication plus réguliers, les équipes technologiques sont incitées à tirer parti de niveaux d’automatisation plus élevés et à adopter des pratiques telles que le développement piloté par les tests.

Risque réduit : avec des déploiements plus petits et plus ciblés, il est moins probable que quelque chose se passe mal que dans des versions plus grandes et plus complexes.

La publication est une décision métier : retirer aux développeurs la complexité des déploiements signifie aussi que la mise en production d’une nouvelle fonctionnalité peut avoir lieu indépendamment d’eux, en laissant aux parties prenantes métier la responsabilité d’appuyer sur le bouton.

Inefficacités exposées : un système de livraison continue peut déplacer l’attention des inefficacités de développement vers les problèmes réels qui les causent, tels que (par exemple) des exigences peu claires.

Pour que le logiciel s’exécute dans chaque environnement, il faut non seulement le code source du logiciel, mais aussi l’infrastructure, telle que les services et les ressources associées dont il dépend. Un exemple courant est une base de données. Si le logiciel nécessite la disponibilité d’une base de données, il faudra en provisionner une pour chaque environnement.

De nombreuses équipes qui développent des logiciels dépendant de bases de données connaissent bien cette situation. Elles disposent de bases de données de développement, d’assurance qualité et de production configurées avec des scripts de provisionnement et de migration. Ces scripts peuvent créer des bases de données pour le schéma correct pour la version actuelle du logiciel, en le mettant à jour d’une version précédente à la version actuelle. Les scripts peuvent également mettre à jour les données réelles, lorsque le modèle de données change de telle sorte que les données existantes ne sont plus valides selon le nouveau schéma. Enfin, l’équipe créera également des tests d’intégration qui valident que la base de données, le schéma et parfois les données sont corrects pour la version actuelle du logiciel.

Cela est également vrai pour le logiciel en tant que service (SaaS) : si le logiciel utilise un produit SaaS, ce service doit être disponible et configuré pour l’environnement donné. Le SaaS est une infrastructure, et pour fonctionner avec la livraison continue, le SaaS doit être traité comme du code.

Contentful permet aux équipes de créer des espaces, qui sont comme des bases de données pour le contenu. Comme dans l’exemple des bases de données ci-dessus, les équipes disposent souvent d’espaces de développement, d’assurance qualité et de production configurés dans Contentful.

Afin de fournir une infrastructure de contenu pour chaque environnement de votre pipeline de déploiement, les espaces Contentful fournissent plusieurs environnements d’espace : dans les environnements de production, où vos éditeurs et auteurs maintiennent votre contenu de production et où vos applications et sites Web interrogent ce contenu, et dans plusieurs environnements bac à sable, un pour chaque étape de votre pipeline de déploiement. Les environnements sont intégrés à chaque étape, de la même manière que les branches sont intégrées à chaque dépôt dans Git.

Un autre défi pour la gestion de contenu est qu’il y a deux cycles de vie qui se déroulent en même temps, tous deux nécessitant une création, une vérification et une publication : l’un est le pipeline de déploiement de logiciels et l’autre est le flux de travail de création de contenu. Alors que les développeurs de logiciels créent et publient des versions de logiciels, les créateurs de contenu créent et publient du contenu en même temps.

Contentful fournit un flux de travail de base intégré, avec des statuts « brouillon » et « publié » qui contrôlent la disponibilité du contenu dans vos systèmes en production, une API de prévisualisation utilisable pour la relecture de contenu, ainsi que des fonctionnalités permettant de créer vos propres flux de travail plus avancés. La création de contenu se fait en utilisant uniquement l’environnement de production dans l’espace du client : les créateurs de contenu créent des brouillons, qui sont examinés via l’API de prévisualisation, puis publiés. D’autres environnements, tels que dev ou QA, ne sont utilisés que dans le cadre du pipeline de déploiement logiciel.

Contentful fournit une plateforme de contenu composable en tant que service qui peut être traité comme du code et inclus dans votre pipeline de déploiement. Pour ce faire, vous devez disposer de scripts de provisionnement, qui peuvent configurer un environnement d’espace avec votre modèle de contenu, et de scripts de migration, qui peuvent migrer un environnement d’espace d’un ancien modèle de contenu vers le modèle actuel et, si nécessaire, modifier les entrées afin qu’elles soient valides selon le modèle actuel. Les équipes doivent également écrire des tests qui peuvent être exécutés pour vérifier que le logiciel actuel fonctionne avec le modèle de contenu actuel et le contenu le plus récent.

Mettre en œuvre le CMS en tant que code (CMS as code) implique d’enregistrer le modèle de contenu dans votre dépôt de gestion de versions, avec le reste de votre code source, afin que la version de la révision logicielle corresponde à celle du modèle de contenu. Cela se fait à l’aide de la Contentful Migration CLI, pour définir la configuration de tous les types de contenu qui ont été ajoutés à l’environnement de développement

La migration initiale peut être créée automatiquement à l’aide de la commande de génération de migration. Les migrations ultérieures sont créées par les développeurs au fur et à mesure que le modèle de contenu évolue.

Lorsque de nouveaux environnements sont créés, ils sont créés en tant que copie de l’environnement de production.

Les bases de données et les plateformes telles que Ruby on Rails ont des stratégies de migration bien développées. Pour le CMS en tant que code, les scripts de migration doivent être écrits par l’équipe. L’outil de migration de Contentful peut aider à la création de tels scripts.

Les migrations traditionnelles de style Rails ont des fonctions up et down pour chaque version de leurs modèles de contenu enregistrés. La fonction up doit pouvoir migrer un environnement d’espace vers la dernière version à partir de la précédente, tandis que la fonction down doit faire l’inverse.

L’expérience sur le terrain montre que, même si les équipes passent de nombreuses heures à maintenir les fonctions down, elles rencontrent souvent des problèmes lorsqu’elles essaient de les utiliser. Il n’existe souvent aucun véritable moyen d’effectuer une migration down du contenu sans avoir recours à des sauvegardes. Par exemple, il se peut que l’ancien contenu ait été supprimé ou que les relations qui étaient auparavant individuelles soient maintenant de type un-à-plusieurs, ce qui signifie que le retour en arrière entraînerait une perte de contenu. Un plan forward-only, ainsi que de bonnes sauvegardes, est généralement une meilleure option.

Un plan de migration forward-only (à sens unique) doit utiliser un modèle d’expansion et de contraction pour apporter en toute sécurité des modifications incompatibles avec les versions précédentes de votre modèle de contenu, au lieu d’écrire des fonctions.

La phase d’expansion doit ajouter de nouveaux champs et types de contenu, et transformer les entrées de contenu de manière à ce que les modifications n’empêchent pas l’exécution de la version actuellement publiée du logiciel. En laissant le contenu existant en place, tout en augmentant les types de contenu et le contenu, la nouvelle version du logiciel peut également s’exécuter. Le modèle de contenu peut désormais prendre en charge à la fois la version actuelle et la nouvelle version de votre logiciel en parallèle. Votre logiciel peut maintenant être distribué à vos utilisateurs d’assurance qualité et déployé sur le reste de votre base d’utilisateurs. Si un problème survient à un moment donné, le déploiement peut être arrêté et annulé.

Une fois que tous les utilisateurs utilisent avec succès votre nouvelle version, la phase de contraction de la migration est exécutée afin de supprimer les types de contenu, champs et contenus devenus inutiles.

À titre d’exemple, imaginons un système de blog qui ne propose qu’un seul type de contenu : l’article. Le type de contenu qu’est un article contient un champ auteur, qui est un champ de texte dans lequel les éditeurs peuvent saisir le nom de l’auteur. Dans la prochaine version du logiciel, de nouvelles exigences entraînent la nécessité que le champ auteur soit un type de contenu indépendant référencé à partir de l’article.

La phase d’expansion ne modifie pas le champ auteur ni son contenu. Elle ajoute plutôt un nouveau champ appelé, par exemple, AuthorRef.

La migration parcourt chaque entrée de publication, crée une nouvelle entrée auteur pour chacun des anciens champs auteur et définit AuthorRef comme référence à cette nouvelle entrée d’auteur.

Vos équipes éditoriales peuvent désormais ajouter des informations supplémentaires aux entrées auteur, tandis que le logiciel existant continue de fonctionner, car il ne dépend que de l’ancien champ auteur.

Lorsque le contenu est prêt, vous pouvez commencer à déployer votre nouveau logiciel. Si des problèmes surviennent à un moment donné, vous pouvez annuler le déploiement.

Une fois le déploiement terminé, votre phase de contraction peut maintenant s’exécuter et supprimer définitivement l’ancien champ auteur. Si vous préférez utiliser le nom de l’ancien champ plutôt que celui défini lors de la phase d’expansion, vous pouvez le faire au moyen d’une autre migration, comprenant sa propre phase d’expansion et de contraction. Si vous pouvez simplement utiliser le nouveau nom, votre migration est terminée.

Si vous vous retrouvez dans une situation où vous devez réellement revenir en arrière, il est recommandé de disposer d’une sauvegarde pour pouvoir restaurer le système. Dans tous les cas, vous pouvez créer une nouvelle migration en avant afin de revenir à l’ancien modèle de contenu.

Contentful fournit des outils d’importation, d’exportation et de migration qui peuvent être utilisés pour faciliter les scripts de provisionnement et de migration, permettant aux équipes agiles de traiter votre CMS comme du code.