Qu’est-ce que le développement « Inner Source » et devriez-vous l’utiliser ? – CloudSavvy IT

Inner Source, souvent stylisé comme InnerSource, fait référence à l’adoption de processus open source et de méthodologies de développement au sein d’une organisation. Alors que « open source » implique la création d’outils accessibles au public, la source interne signifie que vous travaillez sur des projets internes en utilisant des approches ouvertes.

Les workflows open source facilitent la collaboration et l’itération rapide. Les problèmes accessibles au public et les demandes de fusion sur des plateformes comme GitHub permettent à quiconque de contribuer à un projet. Les bogues sont découverts et corrigés rapidement, en toute sécurité et de manière transparente dans un environnement qui favorise une discussion régulière entre les responsables et les utilisateurs.

Ce modèle peut contraster fortement avec la manière dont les logiciels sont développés au sein des grandes organisations. Dans ces environnements, les outils sont développés de manière ad hoc par des équipes individuelles. Les gens travaillent en silos, contribuant à leurs domaines individuels, sans se soucier du travail qui se chevauche ailleurs.

Présentation de la source intérieure

Le mouvement des sources internes applique les leçons apprises du développement open source aux projets internes d’une organisation. Il préconise de rendre tout le code visible à tous, de créer une culture plus ouverte où les équipes peuvent trouver des projets existants qui pourraient également être utiles à leur travail, puis apporter leurs propres améliorations.

Dans de nombreuses organisations, les nouveaux référentiels sources seront verrouillés uniquement pour les personnes qui doivent y travailler. Adopter un modèle de source interne signifie que tout est visible par défaut. Cela encourage les membres de l’équipe à explorer l’ensemble du corpus de code de l’organisation et à contribuer aux discussions, même si le projet ne relève pas strictement de leur domaine.

La source interne ne concerne pas seulement le code non plus. Il peut être étendu pour inclure des actifs et une documentation plus larges concernant l’entreprise, ses opérations et ses logiciels. L’objectif est de donner aux individus les moyens de choisir eux-mêmes des tâches et de partager leur expérience là où ils estiment que cela profiterait à l’organisation, même s’ils sont embauchés dans un domaine d’intervention spécifique.

Avantages de la source interne

Les partisans des architectures de « source interne » notent plusieurs avantages importants de l’approche, notamment une réduction des déchets, des temps de lancement accélérés, moins de tension entre les équipes et une qualité de code améliorée. Ceux-ci se combinent pour améliorer la productivité de l’organisation et la culture du lieu de travail.

• Réduction des déchets, meilleure réutilisation – Les grandes organisations peuvent finir par dupliquer un code similaire sur plusieurs projets appartenant à différentes équipes. Si les équipes ne se parlent pas, le fait que vous ayez maintenant trois bibliothèques de mise en cache similaires pourrait passer inaperçu. La publication de tout le code en interne alertera les autres sur la présence d’outils habituels, puis encouragera l’itération partagée sur une seule base de code. La roue cesse d’être réinventée, gardant tout le monde sur la tâche et accélérant le délai de lancement.
• Qualité de code améliorée – Le code écrit à l’air libre est plus exposé, les bogues sont donc susceptibles d’apparaître plus tôt dans le processus de développement. Si une bibliothèque partagée est adoptée par une nouvelle équipe, des problèmes qui n’avaient pas été remarqués auparavant pourraient apparaître. La mise en œuvre de correctifs profitera à tous les projets utilisant la bibliothèque.
• Moins de tensions entre les équipes – Bien que le passage à un modèle ouvert puisse sembler inconfortable au début, le développement de la source interne est destiné à briser les barrières et à améliorer la collaboration. Le développement fermé peut créer des situations difficiles lorsque vous trouvez qu’une équipe voisine a construit une meilleure version d’une bibliothèque que vous utilisez. Dans un modèle ouvert, cela est résolu en itérant ensemble sur une base de code partagée qui inclut les capacités nécessaires à l’ensemble du groupe.

La source interne aplatit la structure organisationnelle, donnant à tous les développeurs la même vue sur le travail en cours. Accepter des contributions extérieures à l’équipe qui « possède » un projet donne accès à un regard neuf et à un pool élargi de solutions.

Implémentation d’un workflow de source interne

Dans sa forme la plus simple, la source interne est implémentée en vous dirigeant vers votre plate-forme de contrôle de version et en modifiant la visibilité des projets de Privé à Interne. En pratique, vous aurez besoin d’un plan plus réfléchi que celui-ci si vous voulez introduire avec succès le modèle source interne dans un environnement d’équipe existant.

Il y a deux aspects fondamentaux dans toute transition : la communication et les outils. Le premier fait référence à l’éducation des membres de l’équipe sur ce qui se passe et comment ils pourront contribuer aux projets ouverts. Les niveaux d’accès « définir et oublier » seront inefficaces car les gens ne seront pas conscients de leurs nouvelles capacités et du moment où elles peuvent être utilisées.

Le deuxième aspect, les outils, implique la sélection d’utilitaires logiciels appropriés pour gérer le flux de travail ouvert. Une équipe logicielle fonctionnelle utilisera probablement déjà une forme de contrôle de version, telle que GitOps, pour gérer son code. Cependant, les modèles d’utilisation précis peuvent varier considérablement dans l’ensemble de l’organisation.

La source interne fait appel à un modèle de développement unifié qui fonctionnera de manière cohérente dans tous les projets. Cela signifie utiliser au maximum les capacités de Git et de votre plate-forme d’hébergement, telles que GitHub ou GitLab.

Les contributeurs devraient être en mesure de soumettre des modifications dans une demande d’extraction que les responsables examinent et fusionnent ensuite. Les demandes d’extraction doivent être complétées par une suite de tests de réussite qui s’exécute dans un pipeline CI. Cela donne à l’équipe de maintien l’assurance que le changement est efficace et garantit que tous les codes répondent aux mêmes normes. Faire en sorte que la base de code s’auto-vérifie grâce à des tests et des contrôles automatisés aide à éliminer les frictions de l’expérience.

Vous devez également tenir compte de la manière dont les ressources de support telles que la documentation et les listes de problèmes sont stockées et exposées. Créer un wiki d’équipe ouvert pour les documents d’API et les références d’architecture ; assurez-vous que tous les bogues et demandes de fonctionnalités sont suivis dans un emplacement central. Cela permettra aux gens de toute l’organisation de trouver les informations dont ils ont besoin. Il permet également aux individus d’apporter des améliorations à des projets arbitraires dans des périodes plus calmes – n’importe qui peut trouver des rapports de bogues et commencer à les corriger, conduisant à des améliorations dans tous les référentiels en aval.

Inconvénients à considérer

La source intérieure est déjà une réalité dans de nombreuses organisations. Les avantages potentiels sont séduisants dans les situations où une efficacité et un débit accrus sont souhaités. Comme pour toute approche du travail, elle n’est cependant pas nécessairement adaptée à tous les environnements.

L’une des préoccupations les plus fréquentes concernant la source interne est son impact sur la sécurité et la divulgation d’informations. Les similitudes entre la source interne et l’écosystème open source plus large ne s’étendent que jusqu’à présent : le code d’une bibliothèque ou d’un framework ouvert ne contient rien de sensible, alors que vous pouvez traiter avec des systèmes propriétaires étroitement surveillés dans votre rôle au travail.

Il est naturel que certains projets doivent toujours être verrouillés, accessibles uniquement aux parties prenantes et à l’équipe de mise en œuvre directement responsable. Cependant, posséder des projets à enjeux élevés avec une source sensible, où il n’est pas sûr de les rendre visibles dans l’ensemble de l’organisation, ne devrait pas sonner le glas d’une initiative de source interne.

Cela vaut toujours la peine d’ouvrir des projets qui peuvent être exposés en toute sécurité. Vous pouvez également faire abstraction des parties non sensibles des projets privés dans de nouvelles bibliothèques partagées accessibles au public. Cela rapproche les avantages de la source intérieure de vos actifs sensibles sans les révéler réellement.

Un autre défi de source interne est de communiquer les attentes aux développeurs. Les développeurs peuvent se méfier de l’exploration de projets ouverts, en particulier si la source interne est introduite dans une organisation historiquement fermée. Cela peut être résolu de diverses manières, par exemple en allouant du temps aux développeurs pour inspecter le code écrit par d’autres équipes.

Il peut également être utile de commencer petit, en exposant uniquement des bibliothèques de base qui seront utiles à de nombreuses équipes différentes dans l’organisation. Un bon choix peut être un composant bien connu mais privé qui a la réputation d’être peu fiable ou obsolète – pensez à nouveau à « un bogue signalé avec l’ApiClient ». L’ouverture de ce composant permet aux développeurs d’apporter leurs propres correctifs selon leurs besoins, améliorant ainsi la productivité et favorisant la croissance organique de la mentalité de la source interne.

Si vous essayez cette technique, veillez à avertir d’abord les auteurs du projet d’origine – même si cela conduit à une plus grande efficacité globale, certaines personnes pourraient traiter d’autres personnes contribuant au code qui était auparavant « le leur » comme un affront. Communiquez pourquoi la source intérieure est introduite dans l’organisation, ainsi que les raisons spécifiques de l’ouverture de projets individuels.

Conclusion

La source interne fait référence au fait de prendre des méthodes de développement de la communauté open source et de les appliquer à des projets et processus internes. Il facilite l’accès sans entrave au code et à la documentation utiles tout en favorisant la collaboration et la communication.

Mis en œuvre correctement, la source interne peut être un point de différenciation pour une organisation qui réduit la redondance, augmente le débit et favorise une culture de développement plus équitable. Choisir de laisser les projets ouverts par défaut permet aux auteurs originaux de puiser dans le talent humain de l’ensemble de l’organisation. De la même manière que les principaux frameworks et bibliothèques open source récoltent les capacités collectives de la communauté, la source interne peut créer des outils internes qui vont au-delà de ce qu’une seule équipe pourrait réaliser.

La source intérieure peut être difficile à obtenir. Cela peut entraîner une réticence de la part des propriétaires de code et une méfiance de la part des développeurs. Lors de l’introduction de toute forme de développement de source interne, gardez les gens sur la même longueur d’onde en documentant clairement les attentes et les procédures de travail. Tout le monde doit se sentir à l’aise de contribuer pour que tous les avantages de la source intérieure deviennent apparents.