Par Philippe Magne
Il y a énormément de buzz autour de GIT. Dans cet article, nous allons essayer de comprendre d’où vient ce succès et s’il est bien justifié. Nous verrons ensuite comment il peut se positionner dans le monde IBM i.
GIT est à la base un simple outil open source pour gérer le code source de multiples projets. Il a supplanté son ancêtre, CVS. Entre les deux SVN a lui aussi connu son heure de gloire dans les années 2000 mais perd régulièrement du terrain sur GIT. Tout cela pour dire que jusque là rien de bien nouveau sous le soleil.
Alors pourquoi tant de succès ? Est-ce parce qu’il apporte des fonctionnalités révolutionnaires par rapport à ses compétiteurs ? La réponse est clairement non. Il nous faut chercher ailleurs les raisons de ce succès. Est-ce parce que son père fondateur n’est autre que Linus Tordwald, le père de Linux ? Il y a peut-être bien là un début de réponse. Le succès de Git s’est développé à peu près au même niveau et au même moment que celui de Linux lui même…
Sommaire
1. Un standard de facto
Git est devenu un standard de facto. C’est quoi un standard ? C’est un outil ou un langage qui, même s’il n’est pas parfait, présente l’énorme avantage d’être connu du plus grand nombre. La conséquence de cela, c’est que les transferts de compétences se font beaucoup plus naturellement dans les diverses équipes. On peut citer par exemple SQL comme standard de facto. Existe-t-il aujourd’hui un autre langage pour exploiter une base de données ? Non.
Pour Git, ce phénomène va même bien au delà de la gestion du code source. Le cas le plus typique pour l’illustrer, c’est la gestion des configurations hardware. Depuis l’avènement des architectures Cloud, on ne parle plus que « d’infrastructure as a code ». Qu’est-ce que vient faire GIT dans tout cela ? Il permet de tracer tous les changements de configuration. Les acteurs dans ce domaine auraient pu développeur leur propre gestionnaire de versions. Ils ont plutôt décidé de s’appuyer sur un standard.
Mais l’on pourrait citer aussi un point tout aussi symbolique : Microsoft qui, quoiqu’on en dise ou en pense, est l’un des principaux acteurs dans les outils de développement, l’a adopté comme standard depuis de nombreuses années. Ils ont été encore plus loin il y a deux ans en rachetant GitHUB. Ont-ils fait l’acquisition de cette entreprise pour sa technologie ? Certainement pas. Ils auraient pu développer le même produit en peu de temps. Non, c’est pour sa communauté de 32 millions de développeurs et la capacité à influer leurs choix techniques.
Ce succès de Git n’aurait pas été aussi massif sans ses déclinaisons commerciales : GitHub, Bitbucket et Gitlab. Utiliser Git en ligne de commande est plutôt réservé à l’étudiant et au geek, mais quand il s’agit de l’établir comme standard dans une entreprise, autant se diriger vers des interface web un peu « sexy ».
2. Notion de « Social coding »
Ce qu’ont apportés ces outils, c’est un changement radical dans le comportement du développeur. Il n’est plus seul dans son coin. Il fait partie d’une équipe mais aussi d’un réseau. Les développeurs sont devenus aujourd’hui beaucoup plus extravertis qu’auparavant. Ils se forment en partageant plus facilement avec leurs pairs. Ce partage est un facteur clé de qualité et de productivité. Le développeur qui s’enferme pendant des jours pour finir de mettre au point son algorithme est (presque) révolu.
Certains grands groupes achètent ces outils sans même se poser de question sur leur capacité à les implémenter dans leur organisation, simplement parce qu’ils leur servent de support pour attirer de nouveaux développeurs. Avec la transformation digitale, la compétition entre les entreprises pour recruter et garder des développeurs va se faire de plus en plus rude. Créer une structure d’accueil conviviale et surtout déjà connue ne fait pas tout le travail, certes, mais apporte sa pièce à l’édifice.
3. GIT dans le monde IBM i
Et voilà, donc, pourquoi il est aussi important de s’intéresser à cet outil open-source aussi dans le monde IBM i. Même si GIT n’est pas parfaitement adapté à ce monde, il favorise naturellement le dialogue et la collaboration entre des développeurs issus d’horizons différents. En cela, il peut devenir rapidement la colonne vertébrale d’une organisation informatique car il va permettre aux collaborateurs de partager les mêmes outils.
Il nous faut détailler la raison pour laquelle il n’est pas parfaitement adapté au monde IBM i. C’est une simple question d’architecture : Dans le monde distribué, le développeur peut travailler de manière entièrement autonome sur sa propre machine. Il peut gérer son code source, le compiler, le débuguer et l’exécuter. Dans le monde IBM i, le développeur peut gérer son code source en local, mais il a forcément besoin d’être connecté au serveur IBM i pour toutes les tâches subséquentes. Du coup, se pose rapidement la question du « comment fait-on pour gérer de multiples projets en parallèle ? ».
Pour descendre plus en détail sur ce thème, je vous laisse lire l’excellent article de notre directeur technique, Michel Mouchon, sur le sujet.
4. ARCAD indispensable à l’adoption de Git
C’est ici que la technologie Arcad se distingue sur le marché. Depuis toujours, Arcad permet de gérer autant de projets en parallèle que l’on veut sans contrainte particulière. Chaque projet est cloisonné et les programmes peuvent être testés indépendamment les uns des autres.
C’est pourquoi l’adoption de GIT pour les développements IBM i nécessitent ce complément de technologie que l’on trouve dans Arcad. La meilleure façon de réussir l’adoption de l’open source est de le compléter par des licences commerciales par-dessus cet open source. Ce modèle présente de nombreux avantages :
- Cela permet d’embrasser d’authentiques standards sur le marché qui favorisent l’intégration naturelle des technologies.
- C’est l’éditeur qui est responsable du bon fonctionnement des noyaux open source qu’il met à disposition.
- C’est l’éditeur qui a mis au point au méthodologie solide autour de cet outil.
- C’est l’éditeur qui entretient un éco-système de compétences (formations, ressources de consulting, etc…)
En somme, cette approche combine le meilleur des deux mondes et sécurise la transformation des équipes.
Philippe Magne
Président Directeur Général, ARCAD Software
Philippe Magne est le PDG et le Fondateur du groupe ARCAD Software, un éditeur de logiciels international spécialisé dans les solutions multi-plateformes pour DevOps, la modernisation d’applications, l’automatisation des tests et le masquage des données. Il dirige l’entreprise pour produire une gamme de solutions complètes et intégrées, distribuées par IBM dans le monde entier. Philippe est un expert de la modernisation et est un conférencier reconnu dans les événements IBM.
