La Persistance du Problème Backend

Dans la première partie de cet article, nous avons vu comment automatiser la qualité et les tests du Frontend pour gérer un volume élevé de Pull Requests (PRs) de développeurs juniors.

Cependant, même avec un frontend plus stable, l'instabilité du backend persistait. Le code côté serveur, souvent plus complexe et ayant des impacts directs sur les données critiques, était la prochaine zone à sécuriser.

Sécuriser le Backend : Linter et Vérifications Manuelles

J'ai commencé par appliquer une méthode similaire à celle du frontend :

1. Mise en place d'un Linter strict : Des règles customisées et avancées ont été configurées pour garantir un niveau de qualité minimal et l'adhérence aux meilleures pratiques du langage.
2. Preuve de Test Manuels : J'ai exigé que les développeurs incluent des captures d'écran de leurs tests Postman dans la description de chaque PR. Cela assurait qu'ils avaient bien vérifié que leur code répondait aux requêtes attendues avant de soumettre leur travail.

Malgré ces mesures, le problème d'instabilité, souvent lié à des effets de bord ou à des régressions, restait un risque constant.

La Solution Optimale : Ciblez les Tests Automatisés

Dans l'industrie, la solution standard pour l'instabilité est le Test Automatisé complet. Cependant, deux contraintes s'y opposaient :

1. Temps : Écrire des tests pour l'ensemble de l'application prend beaucoup de temps.
2. Compétence : Les développeurs juniors n'auraient pas pu écrire ces tests efficacement ou de manière exhaustive.

J'ai donc fait un choix stratégique d'optimisation : au lieu d'écrire des tests pour tout, j'ai identifié les "points d'étranglement" (ou bottlenecks) de l'application :

• Les zones critiques et sensibles (Authentification, Migrations de base de données).
• Les parties du code qui, si elles échouent, bloquent le fonctionnement de tout le reste (Portefeuille utilisateur, Logique de paiement).

J'ai écrit moi-même des tests automatisés uniquement pour ces modules vitaux.

Le Nouveau Workflow de Revue Backend

Désormais, lorsque je fusionnais le code d'un développeur backend, je n'avais plus la crainte qu'une fonctionnalité périphérique ne casse le cœur de l'application. La CI (que j'ai bien sûr étendue au backend) exécutait ces tests critiques avant toute validation.

Mon rôle s'est encore allégé : je me concentrais principalement sur l'examen des patterns de conception utilisés, rendant la revue de code bien plus rapide et qualitative.

La Sécurité Ultime : Environnement de Staging (Développement)

Pour une sécurité maximale, j'ai introduit une étape supplémentaire :

• Le code fusionné sur la branche principale était déployé dans un environnement de développement/staging.
• Ce n'est qu'après une vérification manuelle finale de l'ensemble de l'application dans cet environnement stable que le déploiement en production était autorisé.

Résultat : Le développement a pu continuer sans heurts. L'application est devenue réellement stable, et nous pouvions déjà utiliser l'application en production avec confiance pendant que les juniors continuaient de coder les fonctionnalités moins critiques.

---

Je ferai une Partie 3 bientôt !

Absolument ! La prochaine étape logique est l'automatisation de ces vérifications manuelles dans l'environnement de staging.

Rendez-vous dans la Partie 3 où nous verrons comment écrire un robot de vérification pour automatiser les tests manuels répétitifs sur l'environnement de développement !