La livraison continue, pour des évolutions faciles et des mises en ligne sereines /

 

     Comment éviter l’apparition de dysfonctionnements sur un site web lors de la maintenance évolutive ? Comment faire tester au client un projet d’évolution de son site sans impacter les internautes ? Comment ne pas perturber l’utilisation d’un site lorsqu’il est «en travaux» ? Ces problématiques sont au cœur de l’approche dite de «livraison continue» développée par Insite avec Drupal 8.

«Intégration continue», «méthodes agiles», «DevOps» : peut-être avez-vous déjà entendu parler de l’un ou l’autre de ces concepts pas toujours simples à comprendre, et qui se recoupent partiellement. Ils font d’une manière ou d’une autre référence à l’idée de bon sens suivante :

Découper un projet en de petites étapes simples et fiables est plus sûr que de tenter de grandes choses d’un seul coup et sans garantie de résultat.

Dans le monde du web, trop de gens l’ont appris à leurs frais !

Si cette approche du «continu» est pertinente, elle n’est pas pour autant instinctive ni facile à mettre en œuvre. À Insite, nous nous sommes donnés pour objectif de développer ce qu’on appelle, pour être précis, la «livraison continue». Il s’agit de travailler autant que possible en cycles courts, en faisant en sorte qu’une nouvelle version du site web puisse «sortir» souvent (dans le jargon : «être déployée»).

Bien entendu, dans le cadre d’un CMS, le client peut faire évoluer quotidiennement et en toute indépendance son site web. Parfois, les internautes eux-mêmes peuvent apporter du contenu (commentaires, contributions diverses,…). La difficulté consiste donc à améliorer le contenant sans impacter le contenu, un peu comme s’il fallait ré-accorder la guitare d’un musicien pendant qu’il joue devant le public.

Comment fonctionne la livraison continue ?

Nous disposons d’une infrastructure qui permet de déployer automatiquement n’importe quelle étape de l’avancement d’un projet web Drupal 8 sur différentes plateformes destinées à différents usages (Application Release Automation) :

 

schemaintecontinue.jpg

 

Dev : Plusieurs développeurs peuvent travailler en parallèle sur un même projet, chacun sur leur machine. Ils peuvent partager entre eux leurs améliorations  à l’aide d’un serveur de gestion de versions (git).

Test : Dès qu’une modification est envoyée sur ce serveur, elle est automatiquement déployée sur une plateforme de test. Cela va permettre d’automatiser une partie des tests pour s’assurer que la modification n’introduit pas un bug. D’autres tests manuels peuvent être réalisés sur cette plateforme par Insite. C’est ce qu’on appelle «l’intégration continue».

Staging : Si les tests internes sont concluants et que le site est déjà en ligne, nous avons la possibilité de déclencher le déploiement automatisé de la version testée sur une plateforme de «staging». Cette plateforme va permettre au client de tester le travail réalisé : à la fois pour vérifier qu’il n’y a pas de bugs, mais aussi et surtout pour confirmer que ce qui a été fait correspond bien à sa demande. C’est le principe de la «livraison continue».

À ce stade, le «vrai site», accessible par les internautes et les robots explorateurs des moteurs de recherche, n’est pas impacté. Le client peut donc tester en toute tranquillité, et ses actions resteront toujours cantonnées à cette plateforme de staging. Il peut par exemple y rédiger de fausses actualités, créer de faux comptes utilisateurs, etc. Pendant ce temps, les développeurs peuvent continuer à travailler et à tester d’autres améliorations en toute indépendance. S’il y a des corrections à apporter, l’équipe technique en sera informée rapidement, et celles-ci passeront par le même circuit : dev -> test -> staging.

Si un chantier au long cours doit être mis en œuvre sur un site existant, pendant que de petites évolutions/corrections doivent être traitées dans l’intervalle, notre infrastructure permet d’avoir plusieurs plateformes de test et de staging en parallèle (branches).

Prod : Lorsque le travail déployé en staging convient au client, il devient possible de le déployer en production. Cela peut être fait très rapidement, au moment qui arrange le client, et les risques sont limités car on sait que la version déployée est fonctionnelle. Dans le cas d’une correction mineure et urgente, il est bien sûr possible de déployer directement en prod sans attendre une validation staging.

Le «vrai contenu» est celui de la prod, c’est là que les rédacteurs et les internautes font vivre le site. En cas de besoin, il est possible d’envoyer ponctuellement ce contenu sur les autres plateformes, pour faciliter les tests.

Preprod : Dans le cas de modifications apportées à un nouveau projet de site, pas encore en ligne, Insite utilise le terme de «preprod». Concrètement, il s’agit de la plateforme qui deviendra la prod, la seule différence étant que son accès n’est pas encore rendu public. Cela permet aux rédacteurs de travailler sur le vrai contenu du site avant sa mise en ligne. Dans la mesure où le site n’est pas encore utilisé par les internautes, l’apparition de bugs en preprod n’est pas critique, donc cette plateforme est souvent utilisée pour les tests du client précédant la mise en ligne (à la place de staging).

 

Ce système est plus complexe que le mode de travail «traditionnel» où des modifications fonctionnelles sont apportées directement en production. Cependant, il permet de réduire fortement les instabilités d’un site en ligne, et facilite grandement les échanges entre le prestataire et le client dans le cadre d’évolutions, ce qui conduit à un gain de temps appréciable. La livraison continue permet finalement de faire évoluer son site web de manière plus régulière, en limitant le recours à des refontes massives et très espacées dans le temps, qui généralement nécessitent de plus lourds investissements et sont plus périlleuses.

Insite a pu répondre à notre projet (…) dans les meilleurs délais. L’équipe sait se rendre disponible et reste à l’écoute de nos problématiques.

Chargée de communication à l'UREI idf