Workflows Git pour les pros : un bon guide Git

Git peut prendre en charge votre projet non seulement avec le contrôle de version, mais aussi avec la collaboration et la gestion des versions. Comprendre comment les modèles de workflow Git peuvent aider ou entraver un projet vous donnera les connaissances nécessaires pour évaluer et adapter efficacement les processus Git de votre projet.

Tout au long de ce guide, j'isolerai les modèles de processus de développement logiciel trouvés dans les flux de travail Git courants. La connaissance de ceux-ci vous aidera à trouver une direction lorsque vous rejoignez, créez ou développez une équipe de développement. Les avantages et les inconvénients de certains types de projets ou d'équipes seront mis en évidence dans les exemples de flux de travail que nous explorons, afin que vous puissiez choisir ce qui pourrait bien fonctionner pour votre scénario.

Ceci n'est pas une introduction à l'utilisation de Git. Il existe déjà de fabuleux guides et de la documentation à ce sujet. Vous bénéficierez de ce guide de workflow Git si vous avez déjà de l'expérience au sein d'une équipe de développement d'applications et avez rencontré des problèmes de workflow, des implosions d'intégration ou des git-tastrophes - ces modèles peuvent vous éclairer sur la façon d'éviter ces situations à l'avenir.

Collaboration

En termes de processus Git, la collaboration consiste souvent à créer des branches de workflows. Réfléchir à la manière dont vous entremêlerez les arborescences de validation vous aidera à minimiser les bogues d'intégration et à soutenir votre stratégie de gestion des versions.

Direction de l'intégration

Utilisez une branche d'intégration avec des équipes de développement de logiciels qui travaillent au déploiement d'un ensemble de contributions en production en tant qu'entité unique. Cela s'oppose aux équipes qui se concentrent sur le déploiement de fonctionnalités individuellement. Souvent, les équipes peuvent vouloir faire ce dernier mais des limitations pratiques imposent un processus qui regroupe leurs efforts, et l'équipe finit par faire le premier, alors assurez-vous de revoir votre utilisation réelle de Git pour voir si vous bénéficieriez de l'utilisation de ce type de collaboration modèle.

Ce modèle de flux de travail est un point de passage utile lorsque le risque d'intégration de plusieurs branches est suffisamment élevé pour justifier le test des contributions combinées dans leur ensemble.

Une branche d'intégration se compose généralement d'une fonctionnalité majeure et de plusieurs contributions plus petites à déployer ensemble. Mettez une branche d'intégration dans le processus de votre équipe de développement (questions-réponses et tests d'acceptation, par exemple). Poussez des commits mineurs dessus pour le rapprocher de la production, puis utilisez une branche d'environnement ou une branche de publication (voir ci-dessous) pour le préparer au déploiement.

Sachez que les contributions sur la branche d'intégration doivent être fusionnées dans la prochaine étape de publication avant qu'une autre fonctionnalité majeure puisse être fusionnée dans la branche d'intégration - sinon vous mélangez des fonctionnalités à différentes étapes d'achèvement. Cela inhibera votre capacité à libérer ce qui est prêt.

Branches thématiques

Les équipes voudront utiliser des branches thématiques s'il est important de conserver leurs arborescences de validation dans un état qui peut être facilement lu ou d'annuler des fonctionnalités individuelles. Les branches thématiques signifient que les commits peuvent être écrasés (en utilisant une poussée forcée) pour nettoyer leur structure et être réduits à un commit de fonctionnalité.

Les branches thématiques appartiennent souvent à un contributeur individuel, mais peuvent également être un espace désigné sur lequel une équipe peut développer une fonctionnalité. D'autres contributeurs savent que ce type de branche pourrait voir son arborescence de commit réécrite à tout moment, et ne devraient pas essayer de garder leurs branches locales synchronisées avec elle.

Sans utiliser les branches thématiques dans votre flux de travail Git, vous êtes limité à vous en tenir aux commits que vous poussez vers une branche distante. Forcer à pousser une nouvelle arborescence de validation vers une branche distante pourrait irriter les autres contributeurs qui comptent sur l'intégrité maintenue de la branche avec laquelle ils se synchronisent.

Il y a de fortes chances que vous utilisiez déjà ce modèle de flux de travail sans vous en rendre compte, mais cela vaut la peine d'avoir un ensemble partagé de définitions entre les équipes pour renforcer les pratiques qui les sous-tendent. Par exemple, vous pouvez trouver que la convention de préfixer le nom de la branche avec les initiales du créateur de la branche aide à signaler quelles sont les branches thématiques. Dans tous les cas, c'est à votre équipe de décider des conventions internes.

N'UTILISEZ PAS les branches thématiques sur les référentiels publics, vous provoquez une myriade de conflits pour quiconque a synchronisé ses branches locales avec une branche thématique dont l'arborescence de validation a été réécrite.

Fourchette

Les projets open source prospèrent grâce à cette fonctionnalité créée par Github. Le fork donne aux mainteneurs du référentiel une passerelle renforcée pour pousser directement vers une branche du référentiel d'origine, mais plus important encore, il facilite la collaboration. Waouh !

Vous pouvez vous retrouver dans le scénario où la création d'un fork d'un référentiel privé répond également à vos besoins. Définir le référentiel d'origine en lecture seule pour les contributeurs du référentiel fork et rouler avec les demandes d'extraction vous offre les mêmes avantages que l'expérience de la communauté open source. Les équipes de différentes organisations peuvent travailler efficacement en utilisant un fork qui peut être la plate-forme de communication et de respect de la politique du projet.

Le modèle de workflow fork donne aux équipes leur propre espace pour travailler de la manière dont elles sont habituées avec un seul point d'intégration entre les deux référentiels - une demande d'extraction. La communication excessive est impérative dans la description de la demande d'extraction. Les équipes ont eu des flux de communication séparés avant qu'une demande d'extraction ne soit émise, et la mise en évidence des décisions déjà prises accélérera le processus de révision.

Bien sûr, l'un des avantages du workflow fork est que vous pouvez diriger les commentaires vers les contributeurs du référentiel d'origine, car les autorisations descendent en cascade. Du point de vue du référentiel d'origine, vous avez le contrôle pour supprimer les fourches lorsqu'elles ne sont plus nécessaires.

Assurez-vous d'utiliser un outil qui facilite les requêtes bifurquées et pull pour tirer parti de ce modèle. Ces outils ne se limitent pas à Github : d'autres choix populaires sont Bitbucket et GitlLab. Mais il existe de nombreux autres services d'hébergement de flux de travail Git qui auront ces fonctionnalités (ou similaires). Choisissez le service qui vous convient le mieux.

N'utilisez PAS un fork d'un référentiel privé pour chaque membre d'une équipe. Les nombreux référentiels fourchus peuvent rendre difficile la collaboration de plusieurs membres sur la même branche de fonctionnalités, et la synchronisation de tous ces référentiels peut devenir sujette aux erreurs en raison du grand nombre de pièces mobiles. Les projets open source ont des membres de l'équipe principale avec un accès push au référentiel d'origine, ce qui réduit cette surcharge.

Cloner

Une stratégie d'externalisation courante consiste à avoir des « sièges » de contribution sur un projet qui peuvent être remplis par plusieurs développeurs de logiciels. C'est à l'entreprise d'externalisation de gérer son pipeline de ressources pour fournir des heures contractuelles, les problèmes auxquels elle est confrontée sont de savoir comment intégrer, former et maintenir un pool de leurs développeurs pour les projets de chaque client.

L'utilisation d'un clone du référentiel du projet constitue un terrain de formation et de communication isolé pour l'équipe externalisée afin de gérer ses contributions, d'appliquer les politiques et de tirer parti du partage des connaissances - le tout sous l'œil vigilant de l'équipe de développement du client. Une fois qu'une contribution est jugée conforme et prête pour le référentiel principal, elle peut être poussée vers l'une des branches distantes des référentiels d'origine et intégrée comme d'habitude.

Certains projets ont des attentes élevées quant au respect de leurs conventions de codage et aux normes de flux de travail Git définies pour contribuer à leur référentiel. Il peut être intimidant de travailler dans cet environnement jusqu'à ce que vous ayez appris les ficelles du métier, alors travaillez en équipe pour optimiser le temps des deux parties.

NE PAS créer une copie hébergée du référentiel du client sans son autorisation, vous pourriez rompre un accord contractuel, vérifiez à l'avance que cette pratique bénéficiera au projet avec le client.

Gestion des versions

Les étapes entre le passage de la collaboration à la publication vont commencer à différents moments du processus de développement pour chaque équipe. En règle générale, vous ne souhaitez pas utiliser plusieurs modèles Git de gestion des versions. Vous voulez avoir le flux de travail le plus simple possible qui permettra à votre équipe de livrer efficacement.

Directions de l'environnement

Votre processus de développement logiciel peut être pris en charge par plusieurs environnements pour aider à l'assurance qualité avant d'être déployé en production. Les branches d'environnement imitent les étapes de ce processus : chaque étape correspond à une branche, et les contributions circulent à travers celles-ci dans un pipeline.

Les équipes qui exécutent ces processus ont souvent des environnements d'application configurés pour chaque étape du pipeline, par exemple "QA", "Staging" et "Production". Dans ces cas, l'infrastructure est en place pour aider le personnel qui est responsable de la signature d'une fonctionnalité ou d'une contribution pour leur tranche de ce que cela signifie d'être prêt pour la production (par exemple, tests exploratoires, AQ, tests d'acceptation), avant de la transférer sur la personne suivante. étape. Cela leur donne leur propre espace pour déployer, tester et évaluer par rapport à leurs exigences, avec un flux de travail Git pour enregistrer son parcours dans le tunnel de signature.

Avoir une branche pour chaque étape du processus est acceptable pour les petites équipes qui peuvent travailler vers une version en tant qu'unité. Malheureusement, un pipeline comme celui-ci peut trop facilement créer des goulots d'étranglement ou se regrouper et laisser des lacunes. Il couple votre processus Git à votre infrastructure, ce qui peut causer des problèmes lorsque la fonctionnalité demande une montée en puissance et que les deux processus doivent évoluer.

N'UTILISEZ PAS ce modèle sans considérer d'abord les avantages à long terme des autres modèles.

Branches de libération

Une équipe qui pousse une collection de contributions vers son application de production en tant qu'unité dans des sprints successifs peut trouver des branches de publication un ajustement favorable.

Une collection de commits presque "prêts pour la production" reçoit des corrections de bugs mineurs sur une branche de publication. Utilisez une branche d'intégration pour combiner et tester les fonctionnalités avant de déplacer son arborescence de validation vers une branche de publication. Limitez la responsabilité d'une branche de publication à une vérification finale avant le déploiement dans l'application de production.

Les branches de version diffèrent des branches d'environnement en ce sens qu'elles ont une courte durée de vie. Les branches de version sont créées uniquement lorsque cela est nécessaire et détruites après le déploiement de son arborescence de validation en production.

Essayez d'empêcher le couplage des branches de version à votre feuille de route de développement logiciel. Se limiter à suivre un plan prédéterminé retarde le déploiement d'une version jusqu'à ce que toutes les fonctionnalités prévues soient prêtes pour la production. Ne pas attribuer de numéro de version à la feuille de route avant de créer une branche de version peut atténuer ces types de retards, en permettant aux fonctionnalités prêtes pour la production d'être placées sur une branche de version et déployées.

Utilisez une convention d'attribution de nom de numéro de version pour le nom de la branche de publication afin de préciser quelle version du référentiel a été déployée en production.

Déployez la branche master et non la branche release. Pour encourager la réalisation de correctifs mineurs sur les branches de publication avant de fusionner avec la branche principale, utilisez un crochet Git sur la branche principale pour déclencher après une fusion afin de déployer automatiquement l'arborescence de validation mise à jour en production.

L'autorisation d'une seule branche de version à un moment donné garantit que vous éviterez les frais généraux liés à la synchronisation de plusieurs branches de version les unes avec les autres.

N'UTILISEZ PAS les branches de publication avec plusieurs équipes travaillant sur le même référentiel. Même si les branches de publication sont de courte durée, si la vérification finale de celle-ci prend trop de temps, cela empêche l'autre équipe de publier. Une équipe s'appuyant sur la branche de publication d'une autre équipe est susceptible d'introduire des bogues et de causer des retards pour les deux équipes. Regardez le modèle de publication horodaté ci-dessous, qui fonctionne mieux pour un plus grand nombre et des groupes de contributeurs.

Versions horodatées

Les applications avec des restrictions d'infrastructure planifient généralement leurs déploiements pendant les périodes de faible trafic. Si votre projet est confronté à des files d'attente régulières de fonctionnalités prêtes à être déployées, vous pouvez bénéficier de l'utilisation de versions horodatées .

Une version horodatée s'appuie sur le processus de déploiement pour ajouter automatiquement une balise d'horodatage au dernier commit sur la branche principale qui a été déployée en production. Les branches thématiques sont utilisées pour mettre une fonctionnalité à travers le processus de développement avant d'être fusionnée dans la branche principale pour attendre le déploiement.

La balise d'horodatage doit inclure un horodatage réel et une étiquette pour indiquer qu'elle représente un déploiement, par exemple : deployed-201402121345 .

L'inclusion de métadonnées de déploiement, sous la forme d'une balise d'horodatage dans l'arborescence de validation de la branche principale, vous aidera à déboguer les régressions publiées dans l'application de production. Il est peu probable que la personne chargée de rechercher la cause du problème en sache beaucoup sur chaque ligne déployée dans l'application de production. L'exécution d'une commande git diff sur les deux dernières balises peut rapidement donner un aperçu des derniers commits déployés et des auteurs des commits qui pourraient aider à résoudre le problème.

Les branches horodatées sont plus qu'elles n'apparaissent à la surface. Un mécanisme simple pour enregistrer un déploiement de fonctionnalités en file d'attente nécessite une quantité surprenante de bons processus pour le piloter. Le processus peut évoluer et fonctionne également bien avec une petite équipe de contributeurs.

Pour que ce modèle de workflow Git soit vraiment efficace, il faut que la branche master soit toujours déployable. Cela peut signifier différentes choses pour votre équipe, mais essentiellement, tous les commits doivent avoir suivi le processus de développement de vos projets avant de se retrouver sur la branche principale.

De nouveaux commits atterrissant sur la branche master vont se produire plusieurs fois par jour. Il s'agit d'un problème pour les branches thématiques qui ont suivi le processus de développement et qui n'ont pas été synchronisées avec la branche principale pendant cette période. Malheureusement, un tel scénario peut introduire des régressions dans la branche master lorsque les conflits de fusion sont mal traités.

Si des conflits de fusion surviennent entre une branche thématique et la branche principale, le risque d'introduire un nouveau bogue doit être discuté avec votre équipe avant de mettre à jour la branche principale distante. S'il existe le moindre doute qu'une régression puisse se produire, la branche thématique peut être renvoyée au processus d'assurance qualité avec les conflits de fusion résolus.

Pour réduire les bogues d'intégration, les développeurs qui travaillent sur des parties connexes du référentiel peuvent collaborer sur le meilleur moment pour fusionner et synchroniser leurs branches thématiques avec la branche principale. Les branches d'intégration fonctionnent également bien pour résoudre les conflits des branches thématiques connexes - celles-ci doivent être soumises au processus de test avant d'être fusionnées dans la file d'attente de la branche principale en attente de déploiement.

Les projets de développement logiciel avec de nombreux contributeurs doivent gérer les processus de collaboration et de gestion des versions avec des approches pratiques et efficaces. Les métadonnées supplémentaires sur l'arbre de validation que nous obtenons en utilisant des versions horodatées sont un indicateur de la prévoyance des équipes qui se préparent à répondre aux problèmes de production.

Branche des versions

Si vous avez un référentiel que vous exécutez non seulement en production, mais que d'autres utilisent pour leurs propres applications hébergées, l'utilisation de branches de version peut donner à votre équipe la plate-forme pour prendre en charge les utilisateurs qui ne restent pas ou ne peuvent pas rester à la pointe des développements de votre application. .

Un référentiel utilisant des branches de version aura une branche par version mineure de l'application. Les versions majeures, mineures et correctives sont expliquées dans la documentation Semantic Versioning. Les branches de version suivent généralement une convention de dénomination pour inclure le mot "stable" et supprimer le numéro de correctif de la version de l'application : par exemple 2-3-stable pour rendre leur objectif et leur fiabilité évidents pour les utilisateurs finaux.

Les balises Git peuvent être appliquées jusqu'au numéro de version du correctif de l'application, mais les branches de version ne sont pas aussi fines. Une branche de version pointera toujours vers le commit le plus stable pour une version mineure prise en charge.

Lorsque des correctifs de sécurité ou la nécessité de rétroporter la fonctionnalité se présentent, rassemblez les validations nécessaires pour travailler avec les anciennes versions d'application que vous prenez en charge, et poussez-les respectivement vers vos branches de version.

N'UTILISEZ PAS les branches de version à moins que vous ne preniez en charge plus d'une version de votre référentiel.

Sommaire

Lorsque votre équipe change de taille ou que votre projet développe ses processus grâce à une évaluation continue, n'oubliez pas non plus d'évaluer votre processus Git. Utilisez les modèles de ce didacticiel comme point de départ pour vous guider sur la voie de la justice du workflow Git.

Le modèle de ce guide peut vous aider à vous armer d'une certaine prévoyance pour adapter votre système de contrôle de version distribué à votre situation. Si vous souhaitez en savoir plus sur les flux de travail Git, assurez-vous de consulter Gitflow, Github Flow et, surtout, l'incroyable documentation git-scm !