Lorsque notre cofondateur et ingénieur associé Dmitriy Zaporozhets a décidé de construire GitLab, il a choisi de le faire avec Ruby on Rails, bien que travaillant principalement en PHP à l’époque. GitHub, source d’inspiration pour GitLab, était également basé sur Rails, ce qui en faisait un choix logique compte tenu de son intérêt pour ce framework. Le PDG de GitLab, Sid Sijbrandij, pense que son cofondateur 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 niveau de qualité élevé », a-t-il expliqué. « Si vous regardez GitLab, il a une énorme quantité de fonctionnalités. Le développement de logiciels est très complexe et pour y parvenir, nous avons besoin de nombreuses fonctionnalités et Ruby on Rails est un moyen d’y parvenir. 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. Vous êtes en quelque sorte guidé pour faire la bonne chose. »
Dépendant des gemmes utiles
Les gemmes Ruby jouent un rôle intégral dans la construction de GitLab, avec le chargement de plus d’un millier de gemmes non uniques, selon Sid. Qualifiant le framework Ruby on Rails de « très opiniâtre », il pense que c’est un environnement solide pour construire une application complexe comme GitLab.
« Il y a un grand écosystème autour de lui avec des gems qui peuvent faire des hypothèses 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 », dit-il. « Si vous regardez notre Gemfile, cela vous donne une indication de la taille de la tour de dépendances sur laquelle nous pouvons nous appuyer. Ruby on Rails a des épaules incroyables sur lesquelles s’appuyer et il aurait été beaucoup plus lent de développer GitLab dans tout autre framework. »
Surmonter les défis
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. Les performances ont été un problème que nos développeurs ont fait des efforts pour améliorer de plusieurs façons, notamment en réécrivant le code en 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, améliorant ainsi l’expérience utilisateur.
Go est utilisé pour résoudre d’autres problèmes affectant les temps de chargement et réduire l’utilisation de la mémoire.
« Ruby a été optimisé pour le développeur, pas pour l’exécuter en production », explique Sid. « Pour les choses qui sont beaucoup sollicitées et qui doivent être très performantes ou qui, par exemple, doivent attendre très longtemps sur une IO du système, nous les réécrivons en Go… Nous essayons toujours de faire en sorte que GitLab utilise moins de mémoire. Nous devrons donc activer le multithreading. Lorsque nous avons développé GitLab, ce n’était pas courant dans l’écosystème Ruby on Rails. Aujourd’hui, c’est plus courant, mais comme nous avons maintenant beaucoup de code et beaucoup de dépendances, le chemin sera plus long pour y arriver. Cela devrait aider ; cela ne le rendra pas flamboyant, mais au moins il utilisera moins de mémoire. »
Ajouter Go à la boîte à outils de GitLab a conduit à la création d’un service séparé appelé Gitaly, qui gère toutes les requêtes Git.
Construire sur la mission de GitLab
Le style organisé et structuré du framework de Ruby on Rails s’inscrit dans notre mission principale. Parce que Rails est simplifié, n’importe qui peut sauter dans GitLab et participer, ce qui l’a rendu particulièrement attrayant pour Sid dès le début.
« Notre mission est que tout le monde puisse contribuer », explique-t-il. « Parce que Ruby on Rails est vraiment opiniâtre sur les pièces qui vont où, il est beaucoup plus facile pour les nouveaux développeurs d’entrer dans le codebase, parce que vous savez où les gens ont mis des choses. Par exemple, dans chaque cuisine où vous entrez, vous ne savez jamais où se trouvent les couteaux et les assiettes. Mais avec Ruby on Rails, vous entrez dans la cuisine et c’est toujours au même endroit, et nous voulons nous en tenir à cela.
Dans chaque cuisine où vous entrez, vous ne savez jamais où se trouvent les couteaux et les assiettes. Mais avec Ruby on Rails, vous entrez dans la cuisine et c’est toujours au même endroit, et nous voulons nous y tenir.
« J’ai été vraiment encouragé lorsque j’ai ouvert le projet et que je l’ai vu pour la première fois un an après que Dmitriy l’ait commencé. Je l’ai ouvert et c’est du Rails idiomatique. Il a suivi tous les principes. Il n’a pas essayé d’expérimenter une sorte de mode qui l’intéressait. Il en a fait une application de production. Dmitriy a soigneusement examiné toutes les contributions pour s’assurer qu’elles respectent ces conventions, et c’est toujours le cas. Je pense que nous disposons d’une très belle base de code qui permet à d’autres personnes de construire par-dessus. L’une de nos sous-valeurs est celle des solutions ennuyeuses : ne faites rien d’extraordinaire. C’est pour que d’autres puissent construire par-dessus. Je pense que nous l’avons très bien fait… et nous sommes vraiment reconnaissants que Ruby ait été un écosystème aussi stable sur lequel nous avons pu construire. »
Cover image by Elvir K on Unsplash
Laisser un commentaire