Développeur, ta prod tu respecteras : Les secrets d'une mise en production réussie | Épisode #2

Une équipe d’experts pour une production réussie

Épisode 2 : Vers la mise en production et au-delà   

 

Mise en production : les étapes préliminaires essentielles 

Avant de lancer la mise en production, l'équipe commence par garantir la mise en place d'un système de sauvegarde des données, qu'il s'agisse de la base de données ou de tout autre média du site. De plus, ils prévoient de mettre en place un mécanisme de retour en arrière (rollback) au cas où surviendraient des imprévus. Cependant, la confiance règne chez nos rongeurs, qui ont tout minutieusement préparé. 

Vient ensuite le moment tant attendu (ou redouté) de la mise en production, et... il n’y a rien à faire. En effet, chaque déploiement réalisé jusqu’à présent équivaut à une mise en production. D’ailleurs, on peut parler de mise en ligne plutôt que d’une mise en production. Ouf, l’équipe n’a pas passé une nuit blanche et le budget café reste raisonnable. Toutefois, le travail de nos rongeurs téméraires ne s’arrête pas là : ils veillent désormais à la pérennité de l'application en production tout en continuant à y apporter des améliorations. 

La production, ça s'entretient !

 

 

Élaborer une stratégie de déploiement de correctifs 

A présent que l’application Hamstergram est en production et qu’elle bénéficie d’une base d'utilisateurs active, le workflow évoluera naturellement. L'équipe réalise un travail de priorisation des retours des utilisateurs et élabore une stratégie de déploiement de correctifs. L’objectif de nos rongeurs consiste à livrer rapidement ces correctifs (hotfixes), plutôt qu’à les réserver à la prochaine version de l’application. Heureusement, grâce aux tests rigoureux effectués par notre équipe d’experts, chaque déploiement est abordé en toute sérénité, avec l’assurance que ces modifications n’affecteront pas l’intégrité de l’application. 

 
Les défis liés aux données 

En mode run, nos hamsters considèrent également les défis liés aux données.  

Alors qu'auparavant, ils utilisaient des ensembles de données fictifs qui pouvaient provenir de Liquibase, ils se servent dorénavant des données issues de la production. Cependant, cette approche entraîne de nouvelles problématiques : dans le cas d’une base de données de production, le volume de données peut être considérable. Le temps d’importation du dump risquerait d’en être impacté... De plus, selon la nature des données, il est essentiel de les obfsuquer de telle sorte que l’équipe de développement n’ait pas accès à des informations sensibles ou personnelles.  

L'idéal serait de disposer d’un environnement de pré-production entièrement identique à la production. Toutefois, l'obtention d'une correspondance totale entre les deux n'est pas toujours réalisable, principalement en raison de contraintes liées à l'infrastructure. 

Caroline et Cheriff ont besoin des données de production pour effectuer des tests et des investigations, c'est pourquoi ils ont pris soin de ne pas disposer de droits d'écriture sur la base de données de production. De plus, ils ont mis en place des mécanismes pour empêcher les commits automatiques sur les transactions et ont respecté les exigences de l'architecture réseau nécessaire pour se connecter aux données de production. Cependant, Jean-Cloud, en tant que hamster averti, leur rappelle qu'ils ne devraient bénéficier d’aucun accès direct à la base de données de production. Ainsi, il propose de mettre en place un système d'exportation des données pour y accéder si besoin. 

 

Comment prévenir les bugs ? 

 
Notre équipe de choc est confrontée à ses premiers bugs de production. Alors que Cheriff éprouve une grande frustration, Caroline et Jean-Cloud relativisent en soulignant que les bugs surviennent inévitablement, mais qu'ils offrent également des opportunités d'apprentissage et d'amélioration du système. L’équipe a bien veillé à disposer des ressources nécessaires pour gérer ces problèmes, que ce soit en termes de personnel, de temps ou de processus. 

Dans cette perspective d'amélioration, il est parfois nécessaire de consacrer du temps à l'analyse des retours d'expérience (REX) afin de prévenir la récurrence de ces problèmes. Dans cette optique, notre trio d’experts peut par exemple présenter un bilan rétrospectif, mettre en place des actions préventives ou encore de solutions pour améliorer l'observabilité. 

Une bonne pratique en matière de prévention consiste à surveiller attentivement les versions des dépendances, que ce soit dès le début du projet en optant pour des versions à long terme (LTS) ou tout au long de la durée de vie du projet afin d'éviter les problèmes de sécurité (Caroline et Jean-Cloud se souviennent bien de la faille Log4J). Cela s'applique également aux versions de nos environnements, qu'il s'agisse du système d'exploitation, des serveurs ou même de la base de données. 

L'équipe est désormais consciente des bonnes pratiques nécessaires pour assurer un fonctionnement optimal de l'application : 

• Adapter son organisation ✓ 

• Prendre conscience que le maintien d’une application dans des conditions opérationnelles participe aussi au métier de développeur ✓ 

• Prévoir des process pour gérer les incidents ✓ 

• Veiller à utiliser les dernières versions des langages et des librairies ✓ 

Est-ce que notre trio d'experts a réellement atteint le degré de perfection de sa production ? Tandis que Cheriff en est convaincu, Caroline, emplie de doutes, file vers une conférence à la recherche d'inspiration pour la perfectionner. Que leur réserve l'avenir ? Cheriff est-il trop optimiste ? Retrouvez les réponses à vos questions dans le prochain épisode !

Quelques articles pour aller plus loin :

Augmentation de la fréquence des déploiements :

Article 1 : Increasing Deployment Frequency Leads to Lower Change Failure Rates - Lien

Résumé : Augmenter la fréquence des déploiements peut conduire à des taux de changement faibles, ce qui rend les déploiements plus faciles 1 .

Article 2 : Why You Should Opt for Regular, Small Releases - Lien

Résumé : Des déploiements réguliers et plus fréquents permettent d'identifier et de résoudre les problèmes plus tôt, simplifiant ainsi les déploiements 2 .

Explication du "You Build It, You Run It" :

Article 1 : Defining You Build It, You Run It - Lien

Résumé : Cette philosophie implique que l'équipe qui construit le logiciel est également responsable de son fonctionnement et de sa maintenance en production 5.

Importance des processus pour la gestion des incidents dans la vie des logiciels :

Article 1 : Incident Management: Processes, Best Practices & Tools - Lien

Résumé : La gestion des incidents vise à réduire le temps d'arrêt et à minimiser l'impact sur la productivité des employés grâce à un flux de travail gérable et répétable pour loguer, diagnostiquer, et résoudre les incidents 7.

Article 2 : Incident management process & tools - Lien

Résumé : La gestion des incidents est cruciale pour les équipes de développement logiciel, car les arrêts de service peuvent coûter cher aux entreprises, soulignant l'importance d'une réponse et résolution efficaces et rapides des problèmes 8.