Explorer la promotion de l’inner source

Le workflow de demande de tirage (pull) basé sur la duplication (fork) est couramment utilisé dans les projets open source, car il permet à tout le monde de contribuer à un projet. Vous n’avez pas besoin d’être contributeur existant ou de disposer d’un accès en écriture à un projet pour proposer vos modifications.

Ce workflow n’est pas réservé aux projets open source : les fourches contribuent également à faciliter les workflows inner source au sein de votre entreprise.

Flux de travail d’équipe traditionnel

Avant les duplications, vous pouviez contribuer à un projet à l’aide de demandes de tirage (pull). Le flux de travail est simple :

1. Poussez une nouvelle branche vers votre référentiel.
2. Ouvrez une pull request pour solliciter une révision de code de votre équipe.
3. Demandez à Azure Repos de contrôler les stratégies de votre branche.
4. Cliquez sur le bouton pour fusionner votre pull request dans la branche principale et déployer lorsque votre code est approuvé.

Ce workflow est idéal pour travailler sur vos projets avec votre équipe. Mais que se passe-t-il si vous remarquez un simple bogue dans un autre projet de votre entreprise et que vous souhaitez le corriger vous-même ? Que se passe-t-il si vous souhaitez ajouter une fonctionnalité à un projet que vous utilisez, mais qu’une autre équipe se développe ?

C’est dans ces situations que les duplications s’avèrent utiles. Les duplications sont au cœur des pratiques sources internes.

Qu’est-ce que la source interne ?

La source interne , parfois appelée « open source interne », offre tous les avantages du développement logiciel open source à l’intérieur de votre pare-feu d’entreprise.

La source interne ouvre vos processus de développement logiciel afin que vos développeurs puissent facilement collaborer sur des projets au sein de votre entreprise. Il utilise les mêmes processus que ceux qui sont populaires dans les communautés de logiciels open source, mais il maintient votre code sécurisé et sécurisé au sein de votre organisation.

Avantages de la source interne

• Collaboration inter-équipes : Teams peut travailler ensemble sur des projets même s’ils ne collaborent pas normalement.
• Partage des connaissances : les développeurs peuvent apprendre du code écrit par d’autres équipes et appliquer ces leçons à leur propre travail.
• Réutilisation du code : au lieu de créer plusieurs fois la même fonctionnalité, les équipes peuvent s’appuyer sur le travail existant.
• Amélioration de la qualité : plus de personnes examinent et contribuent au code entraînent généralement une meilleure qualité des logiciels.
• Innover plus rapidement : Les équipes peuvent avancer plus rapidement en s’appuyant sur des solutions existantes plutôt que de commencer à partir de zéro.

Parcours source interne de Microsoft

Microsoft utilise beaucoup l’approche inner source. Dans le cadre des efforts de création d’un système d’ingénierie dans toute l’entreprise , soutenu par Azure Repos, Microsoft a ouvert le code source de tous les projets à tous les membres de l’entreprise.

Avant la source interne

Avant de passer à la source interne, Microsoft était « cloisonné » :

• Seuls les ingénieurs travaillant sur Windows peuvent lire le code source Windows.
• Seuls les développeurs travaillant sur Office pouvaient voir le code source Office.
• Si vous étiez ingénieur travaillant sur Visual Studio et que vous avez trouvé un bogue dans Windows ou Office – ou si vous vouliez ajouter une nouvelle fonctionnalité – vous n’avez pas eu de chance.

Après la source interne

Cependant, la mise à disposition de sources basées sur la source interne à l’échelle de l’entreprise (avec Azure Repos) simplifie la duplication des référentiels et permet la contribution mutuelle. En tant que personne effectuant la modification, vous n’avez pas besoin d’un accès en écriture au référentiel d’origine, seulement de la capacité de le lire et de créer un fork.

Cette approche a permis :

• Meilleure collaboration entre les équipes.
• Correctifs de bogues plus rapides et développement de fonctionnalités.
• Amélioration de la qualité du code grâce à une révision plus large.
• Réduction de la duplication des efforts entre les projets.