Explorer la promotion de l’inner source
Le workflow de demande de tirage (pull request) basé sur la duplication 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 déjà contributeur ou d’avoir un accès en écriture à un projet pour partager 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.
Avant les duplications, vous pouviez contribuer à un projet à l’aide de demandes de tirage.
Le workflow est assez simple : vous envoyez (push) une nouvelle branche vers votre dépôt, vous ouvrez une demande de tirage pour obtenir une revue de code de votre équipe et vous faites évaluer vos stratégies de branche par Azure Repos.
Vous pouvez cliquer sur un bouton pour fusionner votre demande de tirage dans la branche primaire et effectuer le déploiement quand 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 envisagez d’ajouter une fonctionnalité à un projet que vous utilisez, mais qui est développé par une autre équipe ?
C’est dans ces situations que les fourches s’avèrent utiles. Les fourches sont au cœur des pratiques inner source.
Inner source
L’inner source (parfois appelé « open source interne ») offre tous les avantages du développement logiciel open source dans les limites de votre pare-feu.
Il ouvre vos processus de développement logiciel pour permettre aux développeurs de collaborer facilement sur des projets dans toute l’entreprise.
Il utilise les processus déjà populaires auprès des communautés des logiciels open source.
Cependant, il assure également la sécurité de votre code au sein de votre organisation.
Microsoft utilise beaucoup l’approche inner source.
Dans le cadre de son initiative « One Engineering System » visant à standardiser l’ingénierie à l’échelle de l’entreprise (initiative s’appuyant sur Azure Repos), Microsoft a également ouvert le code source de tous ses projets à l’ensemble des membres de l’entreprise.
Avant le passage à l’inner source, Microsoft fonctionnait en « silos » : seuls les ingénieurs travaillant sur Windows pouvaient lire le code source Windows.
Seuls les développeurs travaillant sur Office pouvaient voir le code source Office.
Ainsi, un ingénieur travaillant sur Visual Studio qui pensait avoir trouvé un bogue dans Windows ou Office (ou qui voulait ajouter une nouvelle fonctionnalité) se retrouvait démuni.
Cependant, la mise à disposition de sources basées sur l’inner source à l’échelle de l’entreprise (avec Azure Repos) simplifie la duplication des dépôts et permet la contribution mutuelle.
Un individu effectuant une modification n’a pas besoin d’un accès en écriture au dépôt d’origine. Il doit simplement pouvoir le lire et créer une fourche.