Deutsche Bahn

L’Express InnerSource : développer la collaboration logicielle chez Deutsche Bahn

Résumé

Lorsqu’il est mis en œuvre efficacement, InnerSource peut créer une immense valeur au sein d’une entreprise en encourageant la collaboration, en améliorant la transparence et en augmentant l’efficacité. InnerSource ne se limite pas au code logiciel : il peut s’appliquer à tout contenu ou processus pour lequel la collaboration et la responsabilité partagée sont bénéfiques.

Chez Deutsche Bahn (DB), InnerSource a joué un rôle déterminant dans la transformation du développement logiciel au sein des filiales. Avec plus de 50 000 dépôts Git actifs et 10 000 utilisateurs de GitLab, DB a identifié une occasion de renforcer la collaboration entre équipes et filiales. En introduisant InnerSource, DB a :

• Créé une culture de collaboration entre les unités opérationnelles et les équipes techniques.
• Réduit les coûts en permettant la réutilisation des composants logiciels et en standardisant l’infrastructure.
• Amélioré la qualité des logiciels grâce aux retours collectifs et au suivi des problèmes.
• Accru la transparence dans le développement et la gouvernance des projets.

Contexte

En tant que l’un des plus grands opérateurs ferroviaires européens, DB possède un écosystème technologique vaste et complexe. L’entreprise gère le développement logiciel dans des centaines de filiales, chacune fonctionnant comme une entité indépendante avec sa propre infrastructure, ses contrats et ses contraintes réglementaires. Historiquement, cette structure a entraîné des inefficacités, une duplication du travail et des difficultés de collaboration entre équipes.

Reconnaissant le potentiel d’InnerSource pour relever ces défis, DB Systel, le partenaire informatique de DB, a lancé une transformation InnerSource. Cette démarche a impliqué des solutions techniques, mais aussi des changements culturels et organisationnels importants pour encourager l’ouverture, la réutilisation et le partage des connaissances.

Le parcours InnerSource de DB a commencé dès 1999 avec l’introduction de Java, suivie de la création d’une bibliothèque de composants partagée en 2002. En 2006, la direction a demandé de publier les projets internes de DB Systel en InnerSource, marquant une transition officielle vers la collaboration ouverte. L’initiative a pris de l’ampleur en 2011 grâce à un atelier de six semaines qui a permis des avancées importantes en matière d’InnerSource. En 2021, face au besoin d’une gouvernance structurée, une équipe dédiée à InnerSource a été créée au sein de l’Architecture Guild pour favoriser son adoption dans l’ensemble de l’organisation.

Problèmes à résoudre

1. Développement en silos entre les entreprises du groupe

Défi : DB comprend environ 500 filiales, chacune constituant une entité juridique distincte. Les obstacles réglementaires et contractuels rendaient difficile le partage de code entre les équipes de l’organisation.

Solution : DB a élaboré la DB Innersource License (DBISL), qui autorise légalement l’utilisation interne libre, la modification et la redistribution des logiciels au sein de DB. Une boîte à outils contractuelle a également été introduite pour intégrer facilement InnerSource aux accords de service.

Le projet DBContainerLib illustre la manière dont DBISL facilite la collaboration. Comme DB regroupe plusieurs filiales ayant chacune leurs propres pratiques de développement logiciel, le partage d’images Docker standardisées et prêtes pour la production était auparavant difficile. Avec DBISL, les équipes des différentes filiales ont pu utiliser, modifier et enrichir librement DBContainerLib, garantissant une image de base cohérente et de haute qualité pour les services en production.

2. Financement et infrastructure des projets InnerSource

Défi : De nombreux projets InnerSource sont nés spontanément d’initiatives de terrain, mais il était difficile d’obtenir une infrastructure et un financement pour ces projets maintenus par la communauté.

Solution : DB a créé l’InnerSource Hub, une plateforme financée de manière centralisée qui fournit des dépôts GitLab, des pipelines CI et des dépôts d’artefacts. Les développeurs ont ainsi pu contribuer aux projets InnerSource sans se soucier des coûts d’infrastructure.

À la date de la dernière mise à jour enregistrée, l’InnerSource Hub héberge plusieurs projets InnerSource maintenus par la communauté, notamment DBContainerLib, PipeShip et K8S Setup. Le financement centralisé a réduit les coûts d’infrastructure de ces projets, évitant à chaque équipe de devoir obtenir ses propres pipelines CI/CD et dépôts d’artefacts.

3. Incertitude et résistance culturelle

Défi : Malgré les fondements techniques et juridiques, de nombreux développeurs hésitaient à partager leur code, doutant du soutien réel de la direction à InnerSource.

Solution : Pour y répondre, l’Architecture Guild a introduit un principe architectural InnerSource, inversant l’attente par défaut : les équipes doivent désormais justifier pourquoi elles n’utilisent pas InnerSource. Ce modèle de gouvernance a rassuré les développeurs : InnerSource était non seulement autorisé, mais activement encouragé.

Les développeurs ont indiqué avoir davantage confiance pour partager leur code depuis l’introduction du principe architectural InnerSource. Beaucoup hésitaient initialement par crainte de voir leur code examiné, mais depuis qu’InnerSource est devenu le choix par défaut, davantage d’équipes ont ouvert leurs dépôts. L’Architecture Guild Microsite en est un exemple notable : les équipes contribuent désormais activement à améliorer la documentation, ce qui assure l’évolution continue de la base de connaissances.

Fondements et mise en œuvre

Une fois les défis fondamentaux résolus, DB Systel s’est attaché à rendre InnerSource accessible et fluide pour les équipes. Cela comprenait :

• L’établissement de consignes de contribution claires pour assurer une collaboration fluide.
• La fourniture d’une infrastructure et d’un financement centralisés grâce à l’InnerSource Hub.
• L’organisation d’actions de formation et de promotion d’InnerSource pour accompagner les équipes et encourager leur participation.
• L’utilisation des bonnes pratiques InnerSource issues de la communauté open source pour guider l’adoption.

InnerSource en action : projets clés

Plusieurs initiatives InnerSource à fort impact chez DB illustrent la réussite de cette approche :

1. DBContainerLib

Une collection d’images Docker prêtes pour la production, maintenue par la communauté.

Principaux avantages :

• Réduction des coûts : évite à chaque équipe de créer et de maintenir ses propres images.
• Amélioration de la qualité : les contributions de différents experts renforcent la sécurité et la conformité.
• Collaboration entre équipes : son utilisation dans plusieurs filiales favorise la collaboration.

DBContainerLib est devenu une ressource essentielle chez Deutsche Bahn : ses seules images basées sur Java atteignent environ 700 000 téléchargements par an. Le projet a été largement adopté par différentes équipes, garantissant des applications conteneurisées standardisées et de haute qualité dans l’ensemble de l’organisation.

2. PipeShip

Un framework modulaire de pipelines CI/CD GitLab maintenu par une équipe plateforme.

Principaux avantages :

• Qualité accrue : les retours des utilisateurs sont intégrés directement au moyen de demandes de fusion.
• Développement plus rapide : les équipes peuvent corriger immédiatement les problèmes et apporter des améliorations.

3. K8S Setup

Un projet d’infrastructure sous forme de code basé sur Helmfile qui simplifie la configuration des espaces de noms Kubernetes.

Principaux avantages :

• Gain de temps : des modèles standardisés accélèrent l’adoption de Kubernetes.
• Transparence : la création de forks permet aux équipes de personnaliser les déploiements tout en maintenant la cohérence.

Avant l’introduction de K8S Setup, les équipes subissaient des délais importants pour configurer les espaces de noms Kubernetes, l’installation manuelle de l’infrastructure prenant souvent plusieurs jours. Grâce à la solution Helmfile fondée sur InnerSource, de nouveaux espaces de noms peuvent désormais être déployés en quelques heures seulement, ce qui améliore considérablement l’efficacité de l’intégration pour les équipes DevOps.

4. Architecture Guild Microsite

Un dépôt de documentation suivant l’approche « Docs as Code ».

Principaux avantages :

• Transparence : les équipes peuvent suivre et enrichir les bonnes pratiques architecturales en constante évolution.
• Collaboration : une participation ouverte améliore la qualité et l’exactitude de la documentation.

Projets futurs

Pour la suite, DB prévoit de :

• Élargir la participation à InnerSource au-delà des équipes logicielles pour inclure les processus métier et la documentation.
• Continuer à affiner les structures de gouvernance pour assurer une croissance durable.
• Identifier d’autres projets InnerSource susceptibles de devenir open source.

Alors qu’InnerSource continue d’évoluer chez Deutsche Bahn, l’entreprise reste déterminée à développer une culture de collaboration, de transparence et d’innovation à grande échelle.