GitLab, le gestionnaire de référentiels Git, a été développé en Ruby on Rails,
Son PDG nous donne ici les raisons de ce choix

Le , par Bill Fassinou

27PARTAGES

11  0 
GitLab, le gestionnaire de référentiels Git basé sur le Web et développé par GitLab Inc. a été développé en Ruby on Rails (RoR), un framework web libre écrit en Ruby qui suit le motif de conception modèle-vue-contrôleur (MVC). Les co-fondateurs du projet nous donnent ici les raisons de ce choix. Lorsque Dmitriy Zaporozhets, cofondateur et membre de l'ingénierie, a décidé de construire GitLab, il a choisi de le faire avec Ruby on Rails, bien qu'il travaillait principalement en PHP à cette époque. GitHub, source d'inspiration pour GitLab, était également basé sur Rails, ce qui en fait un choix logique vu son intérêt pour le framework. Et Sid Sijbrandij, PDG de GitLab, pense que son co-fondateur a fait un bon choix.

« Cela a très bien fonctionné parce que l'écosystème Ruby on Rails vous permet de façonner beaucoup de fonctionnalités à un haut niveau de qualité. Si vous regardez GitLab, il a une énorme quantité de fonctionnalités. Le développement de logiciels est très complexe et pour cela, nous avons besoin de beaucoup de fonctionnalités et Ruby on Rails est un moyen de le faire. Parce qu'il y a toutes ces meilleures pratiques qui sont sur votre chemin heureux, c'est aussi un moyen de garder le code cohérent lorsque vous expédiez quelque chose comme GitLab », explique-t-il dans un billet de blog.

Sid précise que les gems jouent un rôle essentiel dans la construction de GitLab, avec plus d'un millier de gems différents. Rappelons que les gems sont des modules de codes produits par d'autres développeurs qui apportent des fonctionnalités à votre application Ruby. Elles ne se limitent pas à Rails qui utilise lui-même quelques gems. La liste des gems utilisées se situe dans le fichier Gemfile à la racine de l'application. Qualifiant le framework Ruby on Rails de "très impressionnant", il pense que c'est un environnement solide pour construire une application complexe comme GitLab.


« Il y a un grand écosystème autour avec des gems qui peuvent faire des suppositions sur la façon dont vous faites les choses et à cet égard, je pense que l'écosystème Ruby on Rails est toujours sans égal. Si vous regardez notre Gemfile, cela vous donnera une idée de la taille des dépendances sur lesquelles GitLab est construit. Ruby on Rails a des épaules incroyables sur lesquelles se tenir et il aurait été beaucoup plus lent de développer GitLab avec un autre framework », dit-il.

Cependant, Sid tient à souligner que tout cela ne veut pas dire qu'il n'y a pas eu de défis dans la construction de GitLab avec Ruby on Rails. « La performance a été un problème que nos développeurs ont fait des progrès pour améliorer de plusieurs façons, notamment en réécrivant du code dans Go et en utilisant le framework Vue. Ce dernier est utilisé pour réécrire les pages fréquemment consultées, comme les problèmes et les demandes de fusion, afin qu'elles se chargent plus rapidement et améliorent l'expérience utilisateur », a-t-il expliqué. Il a également précisé que Go est utilisé pour résoudre d'autres problèmes affectant les temps de chargement et réduire l'utilisation de la mémoire. Car, « Ruby a été optimisé pour le développeur, pas pour le faire fonctionner en production », dit Sid.

« Pour les ressources qui sont souvent sollicitées et qui doivent être très performantes, nous les réécrivons dans Go. Nous essayons toujours de faire en sorte que GitLab utilise moins de mémoire. Nous devrons donc activer le multithreading (un processeur est dit multithread s'il est capable d'exécuter efficacement plusieurs threads simultanément). Quand nous avons développé GitLab, cela n'était pas courant dans l'écosystème Ruby on Rails. Maintenant, c'est plus courant, mais parce que nous avons actuellement tant de code et tant de dépendances, cela va être difficile pour nous d'y arriver. Ça devrait aider ; le multithreading ne rendra pas GitLab incroyablement rapide, mais au moins il utilisera moins de mémoire », précise Sid.

L'ajout de Go à la boîte à outils de GitLab a conduit à la création d'un service séparé appelé Gitaly qui traite toutes les requêtes Git, dit Sid. « Le style organisé et structuré du framework Ruby on Rails s'inscrit dans notre mission principale. Parce que Rails est rationalisé, n'importe qui peut sauter dans GitLab et y participer, ce qui l'a rendu particulièrement attrayant pour Sid dès le début », peut-on lire dans le billet de blog. « Notre mission est que chacun puisse apporter sa contribution. Parce que Ruby on Rails est bien structuré, il est beaucoup plus facile pour les nouveaux développeurs d'accéder à la base de code, car vous savez où les autres ont mis chacun de leurs bouts de code », explique-t-il.

Rappelons qu'en juin 2018, la version 11.0 de GitLab était disponible avec un ensemble de fonctionnalités d'automatisation, une meilleure gestion des licences et de la sécurité. Les entreprises font face à de nombreux défis pour développer et livrer des logiciels à temps. Heureusement pour elles, GitLab a pensé à tout. En plus de faciliter l'hébergement et la collaboration dans des dépôts publics et privés, GitLab simplifie également le reste du processus en offrant l'ensemble des outils de livraison intégrés. Et maintenant, ce n'est plus seulement intégré, c'est automatisé. Avec sa nouvelle fonctionnalité Auto DevOps, GitLab simplifie et accélère la livraison avec un pipeline de livraison complet prêt à l'emploi. Il suffit de valider le code et GitLab fait le reste. Cette fonctionnalité qui était disponible en version bêta dans le GitLab 10 est maintenant lancée depuis la version 11.0.

Dans le rang des internautes, tout le monde ne partage pas l'avis de Sid Sijbrandij. L'un d'eux affirme que RoR est conçu pour être simple et agréable, mais pas plus et ne rend pas les choses aussi simples qu'elles en ont l'air au premier abord. Un autre attaque Sid en disant qu'il ne s'agit pas de choisir rails sur un coup de tête, construire une petite application et essayer de justifier sa décision plus tard. Pour lui, Rails n'est pas aussi simple comme Sid le sous-tend.

Source : Billet de blog

Et vous ?

Êtes-vous du même avis que Sid ? Pourquoi ?
Avez-vous déjà utilisé RoR une fois ? Partagez votre avis avec nous

Voir aussi

GitLab 11.0 est disponible avec un ensemble de fonctionnalités d'automatisation une meilleure gestion des licences et de la sécurité, entre autres

Gitlab annonce que ses offres Ultimate et Gold sont gratuites pour les projets éducatifs et open source

Comment le DevOps permet de s'adapter aux habitudes numériques de ses clients ? Un exemple de cas d'utilisation avec Société Générale

DevOPS avec Azure - Partie 8 : à la découverte de l'outil App Service Continuous Delivery Par Hinault Romaric

Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur le constat inquiétant de Jeff Knupp

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de adericov
Nouveau membre du Club https://www.developpez.com
Le 26/01/2019 à 17:36
Ruby ne me surprend plus puis que je le considère maintenant comme le meilleur choix dans le developpement de gros sites comme github justement.
Avatar de abriotde
Membre éprouvé https://www.developpez.com
Le 26/01/2019 à 20:53
Je pense que pour développer un logiciel rapidement et le faire évoluer facilement il faut un language interprété. J'aurais préféré PHP ou Python, plutôt plus performants et courant (donc plus facile de recruter). Mais fondamentalement cela ne change pas du tout au tout. Par contre comme il est dit, il viens un moment où pour des questions de performances, il faut un language compilé. De plus en plus j'irais vers C++ voire Rust mais Go est très bien.
En fait le choix qui est fait est toujours le choix de la simplicité en apparence au détriment des performances sur le long terme C'est un choix de manager pas de développeur.
Avatar de grunk
Modérateur https://www.developpez.com
Le 26/01/2019 à 21:18
RoR c'était LE framework a utiliser a l'époque du web 2.0 aujourd'hui j'ai l'impression que c'est quand même un peu en perte de vitesse.
Après je vois pas l'intérêt de justifier un choix technique a partir du moment où le logiciel fait correctement ce qu'on lui demande.

Gitlab est un super outil par contre niveau performance c'est pas dingue. C'est pas mauvais mais j'ai une instance avec ~60 dépôts et 10 utilisateurs (donc pas grand chose) et y bouffe un paquet de RAM.
Avatar de Zefling
Membre expert https://www.developpez.com
Le 27/01/2019 à 2:07
Citation Envoyé par grunk Voir le message
Gitlab est un super outil par contre niveau performance c'est pas dingue. C'est pas mauvais mais j'ai une instance avec ~60 dépôts et 10 utilisateurs (donc pas grand chose) et y bouffe un paquet de RAM.
C'est un peu le problème que j'ai avec Gitlab. Ça bouffe énormément de RAM et de CPU alors qu'il ne fait presque rien. À côté j'ai une dizaine sites en PHP, dont deux beaucoup plus actifs, qui semblent invisibles dans les stats (encore plus depuis PHP 7).
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 27/01/2019 à 13:12
Rails a été une belle révolution de framework cohérent, agréable, productif. Mais Django puis Symfony l'ont copié et on a donc désormais le choix des langages. Ruby et Python sont plus 'propres' et productifs que PHP mais moins performants que le dernier PHP7, et il est plus facile de trouver des devs PHP en France, mais pas forcément de bons dev. Quick and dirty, en Symfony /PHP, ou bien reculer pour mieux sauter en Django/Python, ça va dépendre du dev disponible...
Concernant les performances, si RoR est productif mais lent, leurs créateurs proposent maintenant Phoenix/Elixir, impressionnant, la facilité de Ruby avec la puissance de Go... (et Elm à la place de Vue.JS de Gitlab...). La maturité (et donc l'écosystème devs et libs dispos) en moins.

Et Julia arrive...
Avatar de Laurent Simon
Membre du Club https://www.developpez.com
Le 13/02/2019 à 7:25
Ruby est surtout la principale cause de l'obésité de GitLab qui est relativement lent et très grand consommateur de mémoire.

J'ai été amené à le tester à grande échelle. Gitlab est pour moi la parfaite démonstration de pourquoi Ruby n'est, malheureusement, pas utilisable pour des projets d'entreprise.

Pour qu'il devienne fréquentable, il faudrait progressivement ré-écrire l'intégralité en Go. Si on le compare à Gogs (équivalent de Github écrit intégralement en Go), à périmètre égal (en installant que l'essentiel de GitLab), c'est le jour et la nuit. Gogs est véloce et occupe très peu de mémoire là où, pour le même service rendu, Gitlab est lent, s'accapare toute la mémoire et s'écroule vite sous la charge.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web