Développeur, ta prod tu respecteras : Les secrets d'une mise en production réussie | Episode #1
Il était une fois une application baptisée Hamstergram, un réseau social révolutionnaire conçu pour les hamsters du monde entier (toute ressemblance avec un réseau social existant serait pure coïncidence). Élaborée par une équipe de hamsters de choc, elle bénéficie d’un développement et d’une mise en production irréprochables. Quelles sont les clés de sa réussite ?
Entrez dans les coulisses de sa conception ! Notre équipe vous dévoilera les astuces et les bonnes pratiques qui ont guidé l’application Hamstergram vers le sommet. Êtes-vous prêts à suivre ces intrépides rongeurs vers la route du succès ?
Une équipe d’experts du digital pour une production web réussie
Episode #1 - Le Build : Les bonnes pratiques à mettre en œuvre pour un développement performant
L’équipe (et notamment Cheriff) est prête pour se lancer dans la grande aventure d’Hamstergram. Mais il ne faut pas confondre vitesse et précipitation.
Etape 1 : Un peu d’initialisation avant de démarrer le développement web
Mettre en place un outil de gestion de code
Pour commencer, notre équipe met en place un outil pour centraliser, partager et versionner le code. De nos jours, le choix est évident : l’équipe installera un repository git. Mais en plus d’une simple initialisation, nos hamsters définissent des règles d’utilisation. Le nombre de workflows git est presque infini ! Ainsi, chaque équipe et chaque projet ont la liberté de sélectionner l'approche qui correspond le plus à leur besoin. Toutefois, ce choix n’est pas définitif ! Nos hamsters ont la possibilité de changer de typologie de workflow au cours de la vie de projet. Par exemple, le workflow utilisé en phase de construction d’une version 0 (ou MVP) sera certainement différent d’un workflow utilisé pour une TMA. Ainsi, le workflow évolue naturellement au fil d’un projet.
Documenter son projet de développement
L’initialisation de git offre l’occasion de mettre en place un autre pilier du projet : la documentation. Cette pratique n’est pas la plus appréciée des développeurs, mais il est crucial d’assurer des bases solides dès le début du projet. Après avoir choisi un workflow et défini les potentielles règles d’utilisation de git, il faut le documenter ! N’importe quel développeur intervenant sur le projet doit être en capacité de trouver rapidement des informations quant à la mise en place de l’environnement de développement, du git etc. Il est préférable d’éviter autant que possible les traditions orales et la multiplication des outils de documentation. En ce qui concerne le développement et les outils associés, notre équipe de hamsters favorise la centralisation de la documentation dans le repository git. Cette pratique présente plusieurs avantages :
-
L’utilisation d’un outil unique
-
Une facilité d’utilisation pour les développeurs pour agrémenter / modifier la documentation
-
Une recherche d’informations simplifiée pour les développeurs (particulièrement puissante pour les IDE, comparé à des wikis sur gitlab par exemple)
-
Des langages de devs pour les devs et par les devs avec Markdown ou Asciidoc
-
Un système de gestion de version connu et maîtrisé par les développeurs
-
Un système de relecture et de validation (comme du code).
Notre équipe est pleinement consciente que le fichier README.md de son projet représente déjà une forme de documentation ! Un Readme bien rédigé, à jour, qui renvoie vers les documents essentiels, c’est autant de temps gagné lorsqu’un nouveau rongeur aguerri au développement rejoindra l’équipe.
Etape 2 : Assurer la stabilité du développement web avec l’écriture de tests
L’écriture de tests constitue une phase incontournable pour respecter sa production. Cette étape clef assure une meilleure maintenabilité de l’application ainsi qu’une meilleure évolutivité. Le processus de développement est réalisé de manière beaucoup plus sereine lorsqu'il est accompagné de tests garantissant l'intégrité de chaque élément. De plus, l’écriture des tests optimise la réalisation de montées de version des librairies en veillant à ce qu'aucun problème ne survienne en production, tout en réduisant les dépenses liées aux tests de non-régression.
Écrire des tests, c’est bien ; les lancer régulièrement, c’est mieux ! La valeur d’un test réside dans sa fréquence d’exécution. Nos hamsters s’attèleront dès lors à la mise en place des outils d’Intégration Continue (CI). Cette CI comportera des étapes simples dans un premier temps : build et lancement des tests à chaque commit sur une branche principale et à chaque demande de merge. Ainsi, les tests seront fréquemment exécutés, afin de détecter rapidement toute défaillance due aux modifications apportées.
Les tests automatisés : les alliés d’une production réussie
L’équipe automatisera ainsi un maximum d’éléments, car l'automatisation des tests représente plus qu’un gain de temps (et les hamsters n’ont pas de temps à perdre). Cette étape évite de s’embourber dans des tâches répétitives tout en créant une documentation dynamique. En effet, un simple test offre une compréhension précise du fonctionnement d'un module ou d'une application, tandis qu'un déploiement permet de maîtriser le processus de manière infaillible. De plus, cette démarche est plus fiable qu'une procédure technique d'incident (PTI), car elle nécessite une maintenance constante. Elle facilite le redémarrage des environnements et simplifie la création de nouveaux environnements.
D’autres astuces à suivre pour une livraison infaillible
Dans le cadre de leur livraison, nos hamsters expérimenteront l'approche "Infrastructure as Code" et automatiseront le provisionning, y compris pour les environnements de développement. De plus, l’équipe automatisera le déploiement sur l'ensemble des environnements en veillant à ce que l'application ne soit conçue qu'une seule fois. Elle gérera enfin la configuration des environnements à l'aide de fichiers de properties.
Nos trois experts veillent également à l’alignement de tous les environnements sur les mêmes versions d'OS, de bases de données et de serveurs. Même la plus infime différence dans la version patch doit être évitée, car, comme dirait Caroline : « s’il y a un patch, c’est pour une bonne raison ! ».
Un autre aspect essentiel, sur lequel Caroline est intransigeante, c’est la gestion de la base de données. Pour cela, l’équipe utilise un système de versionning de base de données et son choix s’est arrêté sur la solution liquibase. Cet outil offre la possibilité de consigner chaque modification apportée à la structure et aux données de référence de la base de données à l'aide de fichiers au format XML, JSON, YAML, voire SQL.
Cette pratique garantira l’alignement de la version de la base de données avec la version de l'application. De plus, elle épargnera à notre équipe les erreurs potentielles résultant de l'exécution manuelle de scripts en production. Jean-Cloud a beau être fiable, il demeure un hamster capable de commettre des erreurs. Cette approche confirme que chaque environnement se situe dans la version adéquate.
En complément, voici quelques bonnes pratiques que notre équipe hors pair a dû prendre en compte :
-
Bien séparer les scripts par versions applicatives
-
Posséder des changements atomiques
-
Gérer les différents environnements par profil
-
S'assurer de l'idempotence
-
Tester les rollbacks
La check list étant achevée, notre équipe de choc est désormais fin prête à préparer sa mise en production :
-
Tests écrits ✓
-
Tests automatisés ✓
-
Déploiement automatisé ✓
Comment se déroulera la mise en production ? Nos hamsters passeront-ils la nuit à tenter de déployer leur application ? L’équipe évitera-t-elle les pièges et embûches du passage en prod ? Jean-Cloud épuisera-t-il le budget du projet en cafés ? Vous trouverez les réponses à ces questions et découvrirez de précieux conseils pour réussir sa mise en production dans le prochain épisode...
Nicolas Silvain et Emile Chomton, Experts Techniques
