Aider une autre agence Drupal à résoudre un problème de déploiement.
RCPCH (Royal College of Paediatrics and Child Health) est une organisation professionnelle destinée aux pédiatres au Royaume-Uni. Elle se charge de la formation postuniversitaire des pédiatres et administre les examens du Royal College of Paediatrics and Child Health.
Code Enigma en fournit l'hébergement et gère son service AWS. En fait, dans notre autre étude de cas sur RCPCH, vous pouvez lire comment nous avons veillé à ce que le pic de trafic prévu pendant la période des examens ne se produise pas, même si leur budget était serré.
NDP Studio, une autre agence spécialisée dans le développement Drupal avec laquelle nous nous associons souvent sur des projets, est responsable du développement Drupal du site. Presque toujours, les déploiements prévus se déroulent sans problème. Cependant, à cette rare occasion, lors d'une mise à jour mineure, le déploiement a mystérieusement échoué. RCPCH nous a demandé, avec notre grand plaisir, d'enquêter sur les problèmes de déploiement.
Ce qui a été utile, c'est que RCPCH dispose d'un environnement de pré-lancement que nous avons pu utiliser pour les tests finaux. Cependant, comme cet environnement se trouve sur les mêmes serveurs d'applications que le site réel, toute construction devait avoir lieu en dehors des heures de travail.
Le défi était que l'environnement pré-livraison était construit sur le cluster autoscale principal. Il n'était donc pas possible d'exécuter un déploiement fictif dans cet environnement pré-livraison sans perturber le site en direct. RCPCH reçoit un trafic mondial et il était donc difficile de choisir un moment précis où cela serait possible.
Le déploiement dans l'environnement pré-livraison aurait en effet redémarré les mêmes services que ceux qui servaient la version de production. Cependant, comme il s'agissait d'un cluster et que les redémarrages se faisaient de manière séquentielle, les interruptions étaient presque indétectables.
La situation idéale aurait été de disposer de deux environnements distincts, mais dans l'immédiat, le risque réel pour la production était assez faible.
Ce que nous avons fait
Le code de la branche pre-live différait de celui de la branche live. Nous avons donc renommé la branche pre-live existante et l'avons remplacée par une copie. De cette façon, nous avons pu synchroniser la base de données en direct avec l'environnement en amont, puis effectuer un déploiement test adéquat avant de procéder au déploiement sur live.
Nous avons effectué les tests la nuit et vérifié le résultat de la construction Jenkins. Selon notre enquête, il semble que quelques paquets de Composer génèrent des avertissements, mais la principale erreur semble survenir lors de la reconstruction des caches de Drupal.
D'après les mises à jour de la base de données des entités média ci-dessus, il semble que le déploiement a du mal à gérer le passage de l'utilisation du module media contrib à l'utilisation de media dans Drupal core.
Cela peut être un défi, car il y a des étapes et des séquences qui doivent être respectées.
Nous avons déjà vu des problèmes de déploiement de ce type où des déploiements multiples et incrémentiels ont bien fonctionné sur des environnements de développement ou de stage, mais lorsque ces changements ont été appliqués au site Live en un seul déploiement combiné, les choses échouent en raison de la séquence des mises à jour et du Cache Clear.
C'est pourquoi il est conseillé de tester ces déploiements sur un environnement de test, après avoir synchronisé la base de données en ligne pour obtenir une réplique exacte de l'environnement Live.
Nous sommes ravis de rapporter que nous avons pu résoudre le problème et mettre RCPCH à jour vers Drupal 8.
