Nos équipes pratiquent l'approche de développement basé sur le tronc - un nouveau code est immédiatement ajouté à la branche maître, les branches tierces vivent au maximum plusieurs jours. Et pour que les validations n'interfèrent pas les unes avec les autres, les développeurs utilisent des indicateurs de fonctionnalités - des commutateurs dans le code qui démarrent et arrêtent le travail de ses composants.
Considérez une itération de développement typique: planification, spécification des exigences, création de tâches dans le tracker, développement. Lorsque les tâches sont prêtes, elles sont déployées dans l'environnement de test pour les tests, la branche de publication se stabilise. Puis la sortie arrive enfin et l'équipe peut enfin obtenir de vrais retours des utilisateurs.
Si vous cherchez à réduire le temps de mise sur le marché, c'est trop long. Plus tôt vous recevez des commentaires des utilisateurs, plus vite vous corrigez les erreurs, moins vous passez de temps sur les mauvaises idées, plus vous pouvez consacrer de ressources aux idées réussies.
Pour que les mises à jour atteignent la vente plus rapidement, une itération doit inclure une fonctionnalité. C'est pourquoi il est nécessaire de raccourcir la durée de vie des branches.
Problèmes de succursales de longue durée
Conflits entre commits (Merge hell). Retarder la libération, l'intégration avec un système externe et d'autres facteurs externes peuvent rendre le décompte inopérant.
Difficultés de partage de code. D'autres membres de l'équipe peuvent avoir besoin du code de la nouvelle branche si les fonctionnalités dépendent les unes des autres. Nous devons démarrer une autre branche juste pour accéder à ce code.
Problèmes d'environnement de test. S'il n'y a qu'un seul serveur de test et qu'il existe de nombreuses branches de fonctionnalités, il ne fonctionnera pas pour tester les tâches en parallèle.
Il est difficile d'annuler les changements. Les problèmes après une version sont courants, et si une nouvelle branche de fonctionnalités commence à échouer, les développeurs doivent choisir entre le correctif et l'inversion, aller dans le code source et télécharger à nouveau la solution.
Comment le développement basé sur le tronc résout ces problèmes
Trunk Based Development ( . trunk – « ») – . Gitflow, TBD master. feature- , .
Trunk Based Development , trunk. , , , -. .
trunk -. , . trunk , .
, - , ? Feature Flags.
Feature Flags
, IF-, . – , . : , - . – , .
(toggle router), . , , . ( ), (, , , ..).
Feature Flags
- , :
(release toggles): , , . .
(experiment toggles): A/B , . % , .
(permission toggles): . , .
(ops toggles): . , – , .
### Feature Flags
– .
– - , .
– TBD , .
: LaunchDarkly, Bullet-Train, Unleash. - , - . , .
Open source : Moggles, Esquilo. , , . , , .
: , . , . .
Feature Flags Portal (FF-Portal): Web + REST API . .
Feature Flags Storage (FF-Storage): .
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap , , FF-Storage . FF-Portal FF-configmap.
Microservice (MS): , FF-configmap . FF-configmap, .
FF-ConfigMap, Pod- . ConfigMap, k8s , .
Les drapeaux sont modifiés via le portail, qui envoie un message d'intégration au bus lorsque l'état est mis à jour. Le composant Config Updater met à jour les valeurs d'indicateur dans FF-ConfigMap via l'API K8S.
Enfin sur les tests
La question se pose, comment tester un produit avec des indicateurs de fonctionnalités? À première vue, les indicateurs compliquent ce processus - s'il y a beaucoup de commutateurs, le nombre de tous les états possibles augmente considérablement.
Mais les drapeaux ne dépendent pas toujours les uns des autres. Par conséquent, nous testons deux cas limites pour la version: 1) tous les nouveaux indicateurs sont désactivés et 2) tous les indicateurs sont activés.
La pratique montre que cela suffit généralement.