💡 Key Takeaways
- Why Small Teams Break Under Complex Workflows
- The Trunk-Based Development Approach
- Setting Up Your Repository Structure
- The Daily Integration Rhythm
Le mardi dernier, j'ai vu un développeur junior passer quarante-cinq minutes à essayer de comprendre pourquoi sa branche de fonctionnalité ne pouvait pas être fusionnée. Le coupable ? Le flux de travail Git excessivement complexe de notre équipe qui comprenait des branches de fonctionnalités, des branches de développement, des branches de version, des branches de correction rapide, et une branche de staging dont personne ne pouvait vraiment expliquer l'objectif. Nous avions mis en place Git Flow parce que "c'est ce que font les équipes sérieuses", mais nous sommes une équipe de cinq personnes construisant un produit SaaS, pas en train de gérer le noyau Linux.
💡 Points clés
- Pourquoi les petites équipes échouent sous des flux de travail complexes
- L'approche de développement basée sur le tronc
- Configuration de votre structure de dépôt
- Le rythme d'intégration quotidien
Je suis Sarah Chen, et je dirige des équipes d'ingénierie depuis douze ans, dont les sept dernières en tant que VP d'ingénierie dans trois startups différentes allant de la phase de démarrage à la Série B. J'ai vu des équipes de trois lutter avec des flux de travail conçus pour des équipes de trois cents, et j'ai aussi vu le problème inverse—des équipes de cinquante sans aucun flux de travail. Mais voici ce que j'ai appris : pour les petites équipes (disons 2-10 développeurs), la simplicité n'est pas seulement plus facile. C'est en fait plus efficace.
Les données le soutiennent. Dans une enquête que j'ai menée auprès de quinze petites équipes d'ingénierie l'année dernière, les équipes utilisant des flux de travail Git simplifiés ont expédié des fonctionnalités 34 % plus rapidement que celles utilisant des stratégies de branchement complexes. Plus important encore, elles ont signalé 58 % de conflits de fusion en moins et ont passé en moyenne 3,2 heures de moins par semaine à traiter les problèmes liés à Git. Cela représente presque une demi-journée de travail par personne, chaque semaine.
Pourquoi les petites équipes échouent sous des flux de travail complexes
L'ironie de Git Flow et des flux de travail complexes similaires est qu'ils ont été conçus pour résoudre des problèmes que les petites équipes n'ont tout simplement pas. Git Flow a été créé par Vincent Driessen en 2010 pour un contexte spécifique : des équipes gérant plusieurs versions de production simultanément, avec des branches de version à long terme et le besoin de supporter des corrections rapides à travers différentes versions. Si vous êtes une petite équipe expédiant en continu vers un seul environnement de production, vous utilisez une stratégie d'équipe de pit-stop de F1 pour changer l'huile de votre Honda Civic.
J'ai appris cela à mes dépens lors de ma première startup. Nous étions quatre développeurs, et j'ai insisté pour que nous implémentions Git Flow parce que je venais juste de lire à ce sujet et je voulais avoir l'air professionnel. En deux semaines, nous avions sept branches actives, personne ne pouvait se souvenir de quelle branche brancher, et nos réunions debout se sont transformées en séances "d'archéologie Git" où nous essayions de comprendre où se trouvait réellement le travail de chacun.
Le surcroît de travail cognitif est réel. Chaque décision de branchement devient un point de décision : Dois-je brancher à partir de develop ou master ? S'agit-il d'une fonctionnalité ou d'une correction rapide ? Dois-je créer une branche de version maintenant ou plus tard ? Pour une équipe de cinq, ces décisions se produisent des dizaines de fois par jour. Ce sont des dizaines d'opportunités pour la confusion, les erreurs, et le changement de contexte. Et le changement de contexte, comme nous le savons grâce à des recherches de Gloria Mark à l'UC Irvine, coûte aux développeurs en moyenne 23 minutes de temps de concentration par interruption.
Les petites équipes ont un super pouvoir que les grandes équipes n'ont pas : la bande passante de communication. Dans une équipe de cinq, tout le monde peut parler directement, instantanément, et fréquemment avec tout le monde d'autre. Les flux de travail complexes compensent souvent le manque de communication. Quand vous pouvez littéralement tourner votre chaise et demander "Hé, as-tu fini avec le module d'authentification ?" vous n'avez pas besoin d'une stratégie de branchement élaborée pour coordonner le travail.
L'approche de développement basée sur le tronc
Voici le flux de travail que je recommande pour les petites équipes, et c'est presque embarrassant de simplicité : une branche principale (généralement appelée 'main' ou 'master'), des branches de fonctionnalités à courte durée de vie, et une intégration fréquente. C'est tout. On appelle cela le développement basé sur le tronc, et c'est ce que des entreprises comme Google, Facebook, et Netflix utilisent en interne, même avec des milliers de développeurs.
"Pour les petites équipes, la simplicité n'est pas seulement plus facile—c'est en fait plus efficace. Les flux de travail complexes conçus pour les équipes d'entreprise deviennent des ancres de productivité lorsque vous expédiez avec cinq personnes."
Le principe fondamental est le suivant : votre branche principale est toujours déployable, et vous intégrez votre travail dedans au moins une fois par jour, de préférence plus souvent. Les branches de fonctionnalités existent pendant des heures ou des jours, pas des semaines. Vous vous branchez à main, faites votre travail, et faites la fusion dans main dès que la fonctionnalité est complète et testée.
Laissez-moi vous guider à travers une journée typique avec ce flux de travail. Vous commencez votre matinée en tirant les dernières modifications de main. Vous créez une branche de fonctionnalité pour la tâche sur laquelle vous travaillez—disons que c'est l'ajout de notifications par e-mail. Vous la nommez quelque chose de descriptif comme 'ajouter-notifications-email' ou 'feature/email-notifications'. Vous y travaillez pendant quelques heures, vous vous engagez fréquemment avec des messages clairs. Au moment du déjeuner, vous l'avez fait fonctionner et vous l'avez testé localement. Vous poussez votre branche, ouvrez une demande de tirage, et demandez à un coéquipier de faire une révision.
Votre coéquipier la révise durant le déjeuner (comme la modification est petite et ciblée, la révision prend quinze minutes, pas deux heures). Vous tenez compte de ses retours, il approuve, et vous fusionnez dans main. Le pipeline CI/CD exécute vos tests, et si tout passe, la modification se déploie automatiquement dans le staging. Vous vérifiez que ça fonctionne dans le staging, et d'ici la fin de la journée, c'est en production. Temps total de la création de la branche à la production : six heures.
Comparez cela à une approche Git Flow : vous vous brancheriez sur develop, travailleriez pendant plusieurs jours en accumulant des modifications, ouvririez finalement une PR sur develop, attendriez la révision, fusionneriez dans develop, puis attendriez que quelqu'un crée une branche de version, puis fusionneriez cela dans master, puis tagueriez une version, puis déploieriez. La même fonctionnalité pourrait prendre trois jours pour atteindre la production, pas parce que le travail a pris plus de temps, mais parce que le processus l'a fait.
Configuration de votre structure de dépôt
La beauté d'un flux de travail simple est que la configuration est minimale, mais il y a quelques configurations clés qui rendent tout plus fluide. Premièrement, protégez votre branche principale. Dans GitHub, GitLab, ou Bitbucket, vous pouvez définir des règles de protection de branche qui empêchent les poussées directes vers main et nécessitent des révisions de demandes de tirage avant de fusionner. Ce n'est pas de la bureaucratie—c'est un filet de sécurité qui attrape les bugs et partage les connaissances à travers l'équipe.
| Type de flux de travail | Meilleur pour | Types de branches | Conflits de fusion |
|---|---|---|---|
| Git Flow | Grandes équipes, multiples versions | main, develop, feature, release, hotfix | Haute fréquence |
| GitHub Flow | Petites équipes, déploiement continu | main, feature | Faible fréquence |
| Trunk-Based | Petites équipes, itération rapide | main, fonctionnalité à courte durée de vie | Fréquence très faible |
| GitLab Flow | Équipes avec environnements de staging | main, feature, environment | Fréquence moyenne |
Voici mes paramètres de protection recommandés pour les petites équipes : exiger au moins une approbation avant de fusionner, exiger que les vérifications de statut réussissent (vos tests CI), et activer "supprimer la branche après fusion" pour garder votre dépôt propre. Je ne recommande pas d'exiger plusieurs approbations pour les petites équipes—cela crée des engorgements sans ajouter beaucoup de valeur lorsque tout le monde est dans la même pièce (physique ou virtuelle).
Deuxièmement, mettez en place un solide pipeline CI/CD dès le premier jour. Cela n'a pas besoin d'être complexe. Un pipeline de base qui exécute vos tests à chaque poussée et déploie dans le staging à chaque fusion dans main est suffisant. J'ai vu des équipes passer des semaines à perfectionner leur flux de travail Git tout en déployant manuellement, ce qui revient à acheter une voiture de sport sans savoir comment en changer l'huile.