Skip to main content

Nettoyer les feature flags après la mise en production

Planifiez une session Devin ponctuelle pour supprimer un feature flag et son code mort une fois que votre mise en production s'est stabilisée.
AuthorCognition
CategoryAutomations
FeaturesPlanifications
1

Planifiez le nettoyage au moment où vous livrez le flag

Vous venez de déployer un nouveau flux de paiement derrière enable_new_checkout. Il est activé en production, mais vous voulez une semaine de surveillance avant de vous engager à supprimer l’ancien code. Au lieu de créer un ticket que vous oublierez, planifiez dès maintenant une session Devin ponctuelle — pendant que le contexte est encore frais.Ouvrez la page de création de planification et réglez le type sur Ponctuelle. Choisissez une date après votre fenêtre de surveillance (par exemple, vendredi prochain à 9 h). Sélectionnez un canal Slack pour que votre équipe soit notifiée lorsque la session s’exécute et que la PR est prête. Puis collez votre prompt :
2

Rendez le prompt exhaustif

Les feature flags se cachent à des endroits inattendus — fichiers de configuration, fixtures de tests, commentaires, variables d’environnement. Plus vous mettez de contexte dans le prompt, plus le résultat est propre. Incluez :
  • Comment fonctionnent vos flags — où ils sont définis et comment ils sont vérifiés (par exemple, useFeatureFlag('name') dans React, isEnabled('name') dans les services backend)
  • Ce qu’il ne faut pas toucher — le framework de flags lui-même vs. le flag spécifique (par exemple, « ne modifiez pas src/lib/featureFlags/ — c’est le framework »)
  • Où se trouvent l’ancien et le nouveau code — par exemple « l’ancien checkout se trouve dans src/pages/checkout/legacy/, le nouveau flux est dans src/pages/checkout/v2/ »
  • Périmètre du nettoyage — les commentaires, la documentation, les fichiers .env et les configurations CI qui référencent le flag doivent également être nettoyés
Un prompt avec ce niveau de détail permet à Devin de suivre toutes les références en un seul passage — pas besoin de second passage.
3

Passez en revue la PR lorsqu'elle arrive

Lorsque la session planifiée se déclenche, Devin suit chaque utilisation du flag dans votre base de code, conserve le chemin de code activé, supprime le chemin désactivé et le code mort, nettoie les tests et ouvre une PR. Vous recevrez une notification par e-mail lorsqu’elle sera prête.Une PR typique ressemble à ceci :
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
Avant de fusionner, vérifiez bien qu’aucune logique métier de l’ancien chemin n’aurait dû être conservée — la gestion des erreurs, les événements d’analyse ou les fallbacks pour les cas limites se trouvent parfois dans la branche « disabled ».