Git : Merges automatiques avec hooks côté serveur

Les workflows DVCS des entreprises se mettent en place et les modèles se renforcent. Git apporte une telle flexibilité aux équipes qu'au sein d'une seule entreprise, plusieurs équipes peuvent utiliser différentes approches pour partager le code et collaborer.

Je parle d'expérience, car c'est exactement ce qui se passe chez Atlassian. L'équipe Bitbucket Server travaille différemment de l'équipe Confluence, qui elle-même travaille différemment de l'équipe Jira. Elles ont toutes un processus Agile similaire, mais différentes approches de la création de branches, de l'intégration continue et de l'organisation d'équipe.

En dépit de ces différences, certaines tendances communes émergent. Un paradigme récurrent dans l'industrie est l'utilisation d'un dépôt centralisé avec une branche main, plusieurs lignes de développement stables et le suivi d'un workflow de branche de fonctionnalité où de nouvelles fonctionnalités et corrections de bugs peuvent être développées indépendamment. Cela favorise une intégration rapide et permet aux équipes de tirer parti des gains d'efficacité apportés par le système de contrôle de version décentralisé (DVCS).

Si vous lisez ceci et que réfléchissez un peu, vous pouvez vous demander : si une entreprise suit le workflow du dépôt centralisé ci-dessus, pourquoi aurait-elle encore besoin de forks ?

Le forking est utile et vital, même au sein de l'entreprise. Il y a plusieurs raisons à cela. Avant de les énumérer, revenons un peu en arrière pour donner un peu de contexte et quelques définitions.

Sommaire

1. Qu'est-ce qu'un fork ?
2. Les forks remportent le titre de meilleur process open source
3. Avez-vous besoin de forks dans votre entreprise ?
4. Protégez les composants de base, mais encouragez l'innovation et l'adoption
5. Organisez la collaboration entre les services
6. Réduisez les interférences
7. Interaction simplifiée avec les sous-traitants
8. Interactions des développeurs derrière le pare-feu
9. Conclusions

Qu'est-ce qu'un fork ?

Dans la terminologie récente des systèmes de contrôle de version décentralisés, un fork est une copie distante côté serveur d'un dépôt, distinct de l'original. Un clone n'est pas un fork, c'est une copie locale d'un dépôt distant. Cela diffère légèrement de la définition générale des forks dans le domaine du développement, mais c'est le sens que je vais utiliser dans cet article.

Les forks remportent le titre de meilleur process open source

Si vous étiez sur une île déserte ces dernières années, permettez-moi de vous révéler un fait indiscutable : les forks remportent le titre de meilleur process open source. Ils favorisent la participation en limitant considérablement les obstacles à l'entrée et les frictions liées à la collaboration dans le code.

Tout le monde peut forker un projet open source, et l'auteur initial ne risque aucune sanction ou critique. L'opération est transparente. Il recevra éventuellement un feedback ou des voies d'amélioration sous la forme de pull requests, et c'est tout.

Avez-vous besoin de forks dans votre entreprise ?

Une approche décentralisée entièrement distribuée est efficace pour les équipes open source peu connectées, mais qu'en est-il des équipes d'entreprise qui travaillent dans le même bureau avec un dépôt centralisé ? Les forks sont-ils utiles dans cette configuration ?

Les forks sont incroyablement utiles, même derrière les pare-feu de l'entreprise.

De manière abstraite, les forks peuvent être utilisés au sein d'une entreprise pour gérer la confiance, suivre la maturité des bases de code et faciliter la collaboration entre équipes.

Quelques exemples concrets :

• Protégez les composants de base, mais encouragez l'innovation et l'adoption.
• Organisez la collaboration entre les services
• Réduisez le bruit.
• Simplifiez l'interaction avec les sous-traitants.
• Interactions des développeurs derrière le pare-feu

Examinons-les tous en détail.

Protégez les composants de base, mais encouragez l'innovation et l'adoption

De nombreuses entreprises possèdent des composants de base qui sont réutilisés dans l'ensemble de la société. Ces éléments sont souvent soumis à des politiques plus strictes concernant les personnes autorisées à effectuer des changements, ils ont des garanties de stabilité et des process de révision plus lourds.

Les forks permettent de bien protéger le code autorisé, mais ils encouragent également l'adoption et l'innovation.

Une équipe non autorisée ou un développeur intéressé par le sujet peut forker le projet et commencer à contribuer, sans nécessiter de supervision et sans perturber le travail de l'équipe de base. La collaboration se passe toujours comme d'habitude avec des pull requests et des branches de fonctionnalité.

En maintenant les expériences en dehors des dépôts principaux, on peut gérer et suivre efficacement la maturité des contributions. Les hacks instables restent isolés dans leurs propres forks ; les éléments stables peuvent être mergés dans les composants de base une fois révisés. Pourquoi les forks offrent-ils ces possibilités alors que les clones normaux ne le font pas ? Parce que les forks prennent en charge le bit de suivi : tout le monde peut cloner localement et travailler sur ses propres expériences, mais le fait de pusher ce code vers un fork côté serveur permet de le suivre.

Atlassian dispose de plusieurs bibliothèques de base partagées entre les différents groupes, comme l'interface utilisateur Atlassian. Les forks allègent le fardeau des équipes de base qui les maintiennent. Elles ne sont plus confrontées à des branches de fonctionnalité parasites et à une arborescence désordonnée dans leur dépôt principal.

Organisez la collaboration entre les services

Un autre scénario, malgré tout similaire, est également fréquent : lorsqu'il n'y a pas d'équipe « de base » ou dirigeante sur un composant logiciel donné, plusieurs départements conservent leurs propres versions modifiées de la même infrastructure. Les forks permettent aux équipes d'avoir un contrôle et des garanties sur leurs propres variations. La collaboration entre les services est toujours facile et transparente avec les pull requests et les incroyables fonctionnalités d'intégration de Git.

Réduisez les interférences

Plus les équipes s'agrandissent, plus le bruit des branches de fonctionnalité et des corrections de bug peut devenir trop important pour que les IU s'affichent correctement. L'historique de projet devient si désordonné qu'il est difficile de comprendre ce qu'il se passe et de savoir qu'est-ce que qui est mergé et à quel endroit. Ces outils peuvent alors perdre en efficacité.

À nouveau, les forks permettent aux sous-équipes de collaborer en toute simplicité, mais assurent que les dépôts centralisés dans lesquels ont lieu les intégrations sont aussi propres que possible.

Interaction simplifiée avec les sous-traitants

Les interactions avec les tiers, les sous-traitants et les freelances sont un autre domaine où les forks révèlent leur utilité. En fournissant des forks comme seul point d'accès à vos dépôts pour les sous-traitants, vous bénéficiez de plusieurs avantages :

• Maintenir votre dépôt principal propre et limité.
• Intégrer le travail de tiers après une révision planifiée.
• Conservez le processus de collaboration Git commun.

Interactions des développeurs derrière le pare-feu

N'oublions pas une dernière pièce importante du puzzle.

Forks personnels du développeur ! Un développeur peut être heureux de hacker, d'améliorer et d'optimiser certains éléments de l'infrastructure principale, mais ne souhaite peut-être pas encore partager son travail préalable avec les autres. Souhaitez-vous qu'il pushe du code exclusif stratégique vers un dépôt public ?

Dans d'autres situations, il souhaitera peut-être conserver une approche légèrement différente d'un problème et continuer à bloquer la contribution jusqu'à pouvoir prouver qu'une certaine décision de design sera bénéfique pour son équipe. Pour ce scénario, les forks personnels constituent un excellent choix.

Les forks personnels permettent également les interactions distribuées et non coordonnées qui ont rendu DVCS extrêmement populaire dans les communautés open source.

Conclusions

Les forks ne sont pas la réponse à tous les problèmes de collaboration autour du code, mais ils apportent une solution efficace à plusieurs problèmes. Dans cet article, j'ai présenté quelques arguments indiquant que les forks dans l'entreprise aident à gérer la confiance et la maturité des bases de code, et qu'elles facilitent la collaboration entre équipes.

Pour conclure, insistons sur le fait que la nouvelle livraison de Bitbucket Server inclut la prise en charge exclusive des forks, en plus d'un ensemble complet d'autres fonctionnalités.

Comme d'habitude, contactez-moi (@durdn) ou l'incroyable équipe @AtlDevtools pour plus d'infos sur l'anticipation des tendances en matière de système de contrôle de version décentralisé et sur le contenu Git.

(Crédits : l'image de modèle de création de branches a été initialement forkée depuis la source Keynote git-flow de nvie.