Le saviez-vous ? GitLab, le gestionnaire de référentiels Git, a été développé en Ruby on Rails
Le saviez-vous ? 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
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 ?
Voir aussi
Répondre avec citation
Envoyé par grunk
Partager