Noesi : Agence de design et de développement web
« Ne cherchez pas des clients pour vos produits, mais faites des produits pour vos clients ». Avec cette citation Seth Godin souligne l’importance de concevoir des solutions qui ont pour objectif de répondre aux besoins réels des clients. Il met l’accent sur l’accompagnement et la personnalisation. Cette approche représente l’identité de l’agence Noesi. Son objectif est de fournir une solution clés en main qui répond aux besoins de chaque client individuellement. C’est dans cette démarche que Noesi a été fondé et que j’ai été amené à mettre en place une infrastructure répondant aux fonctionnements complètement en distanciel de l’agence.
Comment les fonctionnalités de GitLab se sont t-elle imposée dans le projet ?
À la fin de ma première année de Bachelor à INTECH, j’ai décidé de créer ma microentreprise en développement web. J’ai continué cette activité pendant trois ans. Lors de mon master à l’ESIEA, j’ai décidé de faire évoluer mon activité en passant d’une micro-entreprise à une SAS. L’intérêt est de pouvoir s’associer avec d’autres personnes pour gérer cette dernière, puis de pouvoir embaucher des employés. Cette démarche s’est inscrite dans une volonté de faire évoluer mes activités entrepreneuriales. Grâce à cette démarche, j’ai pu m’associer avec d’autres experts ayant des compétences complémentaires avec les miennes et j’ai pu commencer à déléguer des tâches. Je me suis associé avec un développeur web et un designer web. Très vite, je me suis rendu compte qu’il fallait améliorer et optimiser le flux de travail des développeurs de l’agence pour pouvoir faire grandir l’agence. Sans cette amélioration, l’agence avait un véritable goulot d’étranglement au niveau de la charge de travail que pouvait gérer un développeur. Par conséquent, j’ai cherché des solutions pour améliorer l’expérience des développeurs au sein de cette dernière. C’est à ce moment que je me suis décidé à mettre en place un GitLab ainsi que des CI/CD. GitLab est un outil adapté aux entreprises qui permet de centraliser le code d’un projet pour faciliter la collaboration entre les développeurs. De plus, il dispose aussi d’un système de versionnement qui permet de revenir facilement à une version précédente si nécessaire. Les CI/CD GitLab sont des fichiers de configuration que nous pouvons placer à la racine des projets GitLab pour automatiser des processus lors de l’ajout de fonctionnalités au sein d’un projet. Par la suite, j’ai mis en place un GitLab au sein de l’agence. Pour cela, j’ai dû prendre en compte le contexte particulier de l’agence qui fonctionne intégralement en distanciel. Il y a donc des risques de sécurité plus importants étant donné que le GitLab sera exposé sur le réseau Internet. Pour y remédier et le sécuriser, un bastion a été mis en place. Un bastion est un intermédiaire qui est exposé sur Internet et qui permet de ne pas exposer le GitLab directement. De plus, il permet d’enregistrer toutes les connexions entrantes et sortantes des utilisateurs qui passent par ce dernier. Une fois le GitLab mis en place, j’ai mis en place des CI/CD GitLab réutilisables suivant les bonnes pratiques, comme les règles appelées « GitLab Flow ». Grâce à toutes ces fonctionnalités, j’ai pu améliorer grandement l’expérience des développeurs tout en améliorant très fortement la qualité de livraisons des projets aux clients.
Quel était le contexte initial du projet ?
Dans le cadre de mes projets d’entrepreneuriat j’ai créé une agence de design et de développement web avec deux associés. Je me suis associé avec un développeur et un designer. L’intérêt était de fusionner nos compétences pour proposer une solution en adéquation avec les besoins de nos clients. Ils sont principalement des petites entreprises et des startups. Le principal rôle que j’ai effectué au sein de l’agence a été la mise en place des principes de la culture DevOps pour améliorer la qualité de nos prestations, tout en réduisant les coûts pour les clients. Une des spécificités de cette agence est son fonctionnement. Elle fonctionne uniquement en distanciel, les outils utilisés pour designer et développer des sites se trouvent dans des clouds. C’est-à-dire que nous utilisons uniquement des outils se trouvant en ligne qui sont gérés sur une infrastructure offerte par le prestataire HyxoHeberg. La culture DevOps est un ensemble de principes qui permettent de simplifier, d’automatiser et d’optimiser les flux de travail entre les équipes de développeurs et les équipes opérationnelles. C’est dans ce cadre que j’ai été amené à rendre viable sur du long terme cette entreprise.
Lors de la réalisation de ce projet, j’ai dû étudier et mettre en place une solution permettant d’améliorer le confort de développement pour les développeurs. La problématique qui en est ressortie très rapidement a été un problème d’uniformisation entre les méthodes des développeurs, ce qui a engendré des projets très difficilement maintenables et non uniformes entre chaque client. Il s’agit du premier enjeu qui est ressorti lors de la réalisation des premiers projets pour des clients. Heureusement, mon travail en alternance est en partie d’intégrer la culture DevOps au sein des entreprises. Et elle répond exactement à cet enjeu en proposant des stratégies de flux de travail pour les développeurs et les équipes opérationnelles. Ce fut ma première expérience d’application de cette culture dans un environnement entièrement basé sur le cloud avec des équipes en distanciel.
Suite à la réalisation du projet, les équipes devront suivre rigoureusement les flux de travail et les résultats des CI/CD GitLab pour assurer l’uniformisation, la maintenabilité et la qualité des projets livrés aux clients ainsi les principes de la culture DevOps bénéficieront directement aux développeurs, aux équipes opérationnels et aux clients.
Pour commencer, j’ai étudié les problématiques rencontrées. Les développeurs avaient des difficultés à travailler en collaboration. Les versions des livrables n’étaient pas toujours conformes aux fonctionnalités livrées. Le code des livrables n’était jamais uniforme entre chaque projet, ce qui rendait le passage d’un client à un autre très fastidieux. La livraison des projets n’était pas définie, ce qui engendrait des confusions sur ce que l’agence devait livrer au client ou non. Les bonnes pratiques et la sécurité n’étaient pas vérifiées au sein des projets réalisés pour des clients. Tous ces problèmes ont fait que l’agence a eu beaucoup de mal à démarrer efficacement. Pour y remédier, je me suis tourné vers les possibilités que pouvait offrir GitLab. Il s’agit d’un outil qui est utilisé par les développeurs pour résoudre ces problèmes, néanmoins, s’il n’est pas configuré, que les stratégies de développement ne sont pas définies et que l’intégration continue n’est pas configurée, les projets peuvent vite être difficiles à maintenir, ce qui engendre des failles de sécurité et des dettes techniques. Étant donné qu’il ne s’agit absolument pas de l’objectif de l’agence, j’ai défini toutes les stratégies liées à GitLab qui se nomment GitLab Flow en fonction des besoins de cette dernière. Et j’ai automatisé les tâches communes entre tous les projets à l’aide de l’intégration et de la livraison continue (CI/CD GitLab) que propose GitLab. Pour y parvenir, je me suis autoformé sur la notion de GitLab Flow et j’ai approfondi mes connaissances en CI/CD GitLab.
Par la suite j’ai mis en application les stratégies définies précédemment. J’ai commencé par configurer le GitLab. Pour cela j’ai activé la fonctionnalité « registry docker ». Elle permet de stocker les projets avec leurs dépendances sous la forme de conteneur Docker. Les conteneurs Docker ont l’avantage d’être supportés dans la majorité des entreprises et d’être simples à mettre en ligne, peu importe l’environnement de déploiement. J’ai créé des CI GitLab pour automatiser les tâches communes à tous les projets des clients, comme la gestion des versions des applications développés, la mise à jour du fichier « CHANGELOG.md » qui contient l’intégralité des changements de la dernière version créé, la possibilité de livrer le projet en un clique. Pour que cette dernière fonctionnalité soit activée, les développeurs devront valider les tests de qualité et de sécurité de leur code. J’ai défini les tests et les règles de développement et de livraisons des projets directement au sein des CI. À l’aide de ces travaux, je vais pouvoir répondre à la majorité des problématiques rencontrées par les développeurs et lors des livraisons des projets aux clients.
Je maîtrise déjà la culture DevOps et je l’ai déjà mise en place dans des environnements d’entreprise. Néanmoins, je n’ai jamais appliqué cette culture dans un environnement fonctionnant complètement en distanciel et ayant des dépendances dans plusieurs clouds différends. Mes seules expériences ont toujours été dans des environnements hors réseau Internet. Par conséquent, je devrais prendre en compte ce nouvel aspect et faire particulièrement attention à l’utilisation des bonnes pratiques. Je devrais aussi faire attention à la robustesse de mes travaux pour éviter toute problématique de sécurité qui pourrait mettre en danger l’agence, nos clients et les outils que nous utilisons en ligne.
Quelles ont été les étapes principales du déroulement de ce projet ?
Définition du besoin
Dans cette première étape, j’ai défini les besoins des développeurs de l’agence. Il s’agit d’une phase importante du projet, car elle va me permettre de définir les objectifs et le périmètre du projet. Plusieurs points de frictions ont été relevés par les développeurs. Dans un premier temps, ils n’ont pas de flux de travail définis, c’est-à-dire qu’à partir du moment où ils se voient attribuer un projet, ils peuvent travailler comme ils le souhaitent. C’est problématique, car les développeurs ne suivent pas forcément les mêmes pratiques de code. Ce qui fait que l’on se retrouve avec différents styles de développement et des projets qui sont très complexes à maintenir. D’autres points ont été relevés. La gestion des versions ou des livraisons pourrait être simplifiée, voire automatisée. Des tests de qualité du code pourraient être mis en place pour s’assurer que tous les développeurs suivent les bonnes pratiques. Ça permet aussi d’uniformiser un minimum le code et de le rendre plus maintenable sur du long terme. Des tests de sécurité pourraient aussi être ajoutés, car pour le moment, il n’y en a aucun. Ce qui est dangereux étant que nous développons des applications web qui ont pour suite d’être exposées sur Internet. L’objectif de ces travaux est de définir, uniformiser et fluidifier le flux de travail des développeurs. C’est essentiel pour qu’ils puissent se développer plus vite et collaborer entre eux.
Tout au long du projet, j’ai utilisé la méthode Kanban. Cette méthode permet de définir des tâches sous forme d’étiquettes, de les prioriser et de leur définir un statut. Ces étiquettes se retrouvent dans un tableau avec quatre colonnes « À faire », « En cours », « Bloqué » et « Terminée ». Je n’ai qu’à prendre les étiquettes une à une dans la colonne « À faire » et à les glisser dans les autres colonnes pour changer leur état et avoir un visuel efficace sur l’état d’avancement du projet. Je n’ai pas eu à utiliser des méthodes plus complètes comme méthode SCRUM étant donné que j’ai travaillé seul sur ce projet. Néanmoins, la méthode Kanban est utilisée dans une grande majorité des méthodes modernes comme SCRUM. Il est important de la maîtriser.
Durant le projet, j’ai réalisé plusieurs documentations au format Markdown. L’intérêt du format Markdown est que les développeurs et les outils utilisés par ces derniers ont le pris en charge. Les développeurs travaillent avec ce langage sur tous les projets de développement web. Il permet de définir des documentations stylisées très efficacement en utilisant un système de balises. Ce fût le candidat idéal pour ce projet. Dorénavant, ces documentations sont automatiquement ajoutées à tous les projets de l’agence dans le répertoire « docs ». De cette manière, les développeurs peuvent se référencer en cas de doutes sur telles ou telles procédures.
Pour finir, ce projet répond parfaitement à mes compétences, étant donné que je travaille sur la mise en place de la culture DevOps au sein des entreprises. Malgré mon expérience, j’ai dû réaliser de gros travaux de recherche pour me former aux stratégies de flux de travail. C’est une notion que je n’avais jamais eu à travailler dans mes anciens projets, étant donné qu’elle était déjà souvent en place dans les équipes dans lesquelles j’ai travaillé. Par conséquent, j’ai approfondi mes connaissances en me documentant sur les principes de flux de travaux nommés GtiLab Flow.
Réalisation
a. GitLab Flow
J’ai commencé par mettre en application la stratégie GitLab Flow. Elle permet de définir une stratégie d’utilisation des branches Git. Il s’agit d’un outil qui permet de centraliser et de versionner le code d’un projet. L’objectif est de faciliter son développement et la collaboration entre les développeurs. Un projet Git est défini avec une branche principale par défaut appelée « main » où se trouvera le code du projet. Lorsqu’un développeur va vouloir rajouter du code à cette branche, il devra créer une seconde branche nommée « feature/ma-fonctionnalite ». Ce nommage permet d’identifier immédiatement l’objectif de la branche. Dans ce cas, il s’agira de l’ajout d’une fonctionnalité. Néanmoins, il peut aussi s’agir de correction de bugs « fix/ma-correction » ou d’une correction à ajouter immédiatement au code du projet avec « hotfix/ma-correction-urgente ». Si les développeurs modifient la même partie du code ils ne seront pas impactés car ils seront dans des branches différentes. Ça permet aussi aux développeurs de tester leur code et de s’assurer qu’il fonctionne et respecte les normes de qualité avant de l’intégrer à l’application finale.
Pour aller plus loin, j’ai rajouté une branche intermédiaire appelée « develop ». Les développeurs doivent fusionner leur branche dans cette dernière et non pas dans la branche « main » directement. De cette manière, nous pouvons décider de quand nous montons la version du site en ligne et nous assurer une seconde fois que les nouvelles fonctionnalités fonctionnent correctement ensemble. Cette stratégie nous a permis d’uniformiser la stratégie de développement utilisée par les développeurs de l’agence. J’ai aussi noté une amélioration de la qualité des livraisons des clients. Qui est accentué par l’ajout de plusieurs étapes de test avant la livraison finale au client.
b. Tests de qualité et de sécurité
Pour améliorer la qualité générale des projets, j’ai rajouté deux nouvelles notions : les tests de qualité du code appelés « lint » et un test de sécurité avancé. Un lint permet de vérifier qu’un code suit bien les conventions et les bonnes pratiques du langage. En cas d’échec du test, un rapport est généré que le développeur peut lire pour améliorer la qualité du code. J’ai testé la qualité du code de l’application web, mais aussi le code de l’image Docker. Une image Docker est un paquet qui va contenir notre application et ces dépendances pour fonctionner. C’est cette image qui sera déployée sur une infrastructure qui le permet pour la rendre disponible sur Internet. Sa sécurité est par conséquent primordiale. Pour ce dernier j’ai utilisé l’outil Trivy, c’est un outil très puissant qui permet d’analyser les dernières failles de sécurité découverte officiellement, de cette manière, nous pouvons nous assurer que lors de nos livraisons, nos applications ne seront pas atteintes par des nouvelles failles de sécurité. Leurs données sont mises à jour tous les jours, ce qui permet d’assurer une certaine qualité au niveau de la sécurité. Ces tests sont définis dans un fichier « .gitlab-ci.yml » et sont exécutés par GitLab lorsque du nouveaux codes sont détectés.
J’ai décidé de mettre les tests ci-dessus en bloquant, c’est-à-dire que si le lint ou la sécurité ne passe pas, le développeur ne pourra pas aller plus loin et ne pourra pas livrer son code. L’objectif est de protéger nos clients, leurs utilisateurs, notre prestataire qui met en ligne et maintient les sites ainsi que notre agence. Finalement, ces tests, nous ont permis de supprimer complètement les problèmes liés à l’ajout de nouvelles fonctionnalités sur les applications en production. Sans ces derniers, ça n’aurait pas été possible.
c. Hook, Conventional Commit, Semver, Changelog, Releases
Dans la continuité de la mise en place d’un environnement de développement fiable, j’ai décidé d’automatiser les tâches identiques à tous les projets clients et créant de la friction avec les développeurs. L’objectif était que chaque version livrée à un client devait être traçable, cohérente et conforme aux bonnes pratiques de développement. Pour y parvenir, j’ai intégré plusieurs notions comme les hooks Git, la convention Conventional Commit, le versionnement Semver, la génération automatique du fichier CHANGELOG.md et la création automatique de Releases GitLab. Ces éléments régissent l’ensemble du cycle de vie d’un projet. Les hooks Git permettent de lancer automatiquement des actions lorsque le développeur travaille avec Git. S’il envoie son code sur GtiLab des tests s’effectueront directement sur son poste. J’ai mis en place un pre-commit hook permettant de vérifier que le message de commit suit la convention Conventional Commit. Cette convention impose une structure stricte aux messages de commit, facilitant leur lecture, leur compréhension, mais surtout leur traitement automatique. Un commit est une action qui permet d’ennregistrer les modifications de code effectuées sur son poste, puis de les envoyer à la plateforme de centralisation du code, dans notre cas GitLab. Par exemple, un commit suivra la forme « type(msg): mon message » et sera interprété comme une nouvelle fonctionnalité ou une correction de bugs. Il y a de nombreux types possibles.
En combinant cette convention au système de versionnement Semver (Semantic Versioning), nous avons pu automatiser la gestion des versions. En fonction de s’il s’agit d’une feature, d’un changement majeur ou d’une correction de bugs, la version se verra incrémentée différemment en se basant sur le Conventional Commit appliqué précédemment. Un changement majeur incrémente automatiquement la version majeure, une nouvelle fonctionnalité incrémente la version mineure, et une correction de bugs incrémente la version patch. Voici le format d’une version « VERSION_MAJEUR.VERSION_MINEUR.VERSION_PATCH », ce qui peut nous donner des versions qui ressemblent à « 2.8.3 ». Cette méthode garantit un historique des évolutions du projet. J’ai aussi automatisé la génération du fichier « CHANGELOG.md ». Pour cela je me base sur les messages des commits Git. Une CI GitLab déclenche la livraison, lorsque le développeur clique sur le bouton « Livrer ». Ce changelog est par la suite inclus automatiquement dans la livraison du projet. Elle contient à la fois l’historique des modifications et le code source du projet. Ce mécanisme permet de garder un historique détaillé de l’évolution du code. Pour les clients, ils obtiennent une meilleure lisibilité des changements apportés à leur application, et pour les développeurs, ils obtiennent une charge mentale plus réduite et un processus de livraison plus fiable et surtout plus professionnel. Grâce à cette automatisation, chaque projet bénéficie désormais d’une gestion des versions rigoureuse, d’une documentation systématisée, et d’une amélioration continue de la qualité du code livré.
d. Solution finale
Pour conclure, je suis particulièrement fier d’avoir mené à bien ce projet en autonomie. Il m’a permis d’approfondir mes compétences autour de la culture DevOps. De plus il s’agissait d’un contexte totalement en distanciel ce qui est une première pour moi. Ce projet m’a permis d’expérimenter, de réfléchir profondément aux stratégies de développement pour les développeurs, mais aussi d’approfondir mes connaissances actuelles autour de la culture DevOps. Il m’a permis de structurer l’ensemble des flux de travail des développeurs au sein de l’agence en y intégrant des outils puissants comme GitLab, les CI/CD, le GitLab Flow, le lint, les tests de sécurité avec Trivy, les Hooks, les commits conventionnels, Semver, les Changelog et les Releases. Tous ces éléments ont été mis en place dans l’objectif d’améliorer l’expérience développeur (DX) et d’augmenter la qualité des projets livrés aux clients.
Qui sont les parties prenantes impliquées dans ce projet ?
J’ai réalisé ce projet durant mon temps libre. Pour le réaliser, je me suis associé avec un développeur et un designer. J’ai aussi conclu un partenariat avec HyxoHeberg qui a mis son infrastructure à disposition afin de mettre en place le GitLab. L’agence a pu bénéficier de leur expertise pour réaliser ce projet. Le développeur a joué le rôle de bêta testeur et a pu faire des retours tout au long du projet que j’ai pris en compte afin de m’assurer de répondre au mieux à ces besoins. J’ai aussi pu bénéficier de l’expérience que j’avais acquise durant mon stage et mon alternance au Ministère des Armées. En combinant mon expérience et les retours du développeur j’ai pu mettre en place un projet solide qui suit toutes les bonnes pratiques de la culture DevOps pour les flux de travaux des développeurs.
Quels bénéfices GitLab nous a-t-il apporté ?
Je suis particulièrement fière d’avoir créé et formé une entreprise autour d’une équipe composée de passionnés dans des domaines complémentaires permettant d’offrir une forte plus-value aux clients. J’ai pu mettre en place une solution permettant d’améliorer grandement l’expérience des développeurs, aussi appelée « DX ». Sur du court terme, j’ai pu constater des gains immédiats au niveau de la qualité des projets livrés. Et j’ai pu avoir des retours très positifs de la part du développeur de l’agence pour son confort de travail. Ces gains s’expliquent par l’ajout d’outils permettant d’accompagner le développeur tout au long des projets, comme l’analyse automatique de la bonne utilisation des bonnes pratiques ou encore la détection automatique des failles de sécurité. Tous ces outils permettent de diminuer fortement l’ajout de bugs dans les projets et limitent les frictions lors du travail de développement. Les développeurs passent plus de temps à développer des fonctionnalités qui ont une forte valeur. Sur du long terme, le chiffre d’affaires devrait augmenter de plus de 20%. Ce qui représente le gain de temps moyen relevé sur la réalisation de quatre projets différents. Ce temps gagné devrait permettre de travailler sur des tâches avec une forte valeur ajoutée et se répercuter directement sur le chiffre d’affaires. De plus, les développeurs disposent d’un environnement de développement plus simple et puissant. Par conséquent, ils sont plus satisfaits et le risque de turnover très présent dans l’industrie de l’informatique se voit baisser drastiquement. Il y a aussi un impact direct sur les clients, qui voient la qualité de leur projet s’améliorer sans devoir payer plus. Ils sont donc plus satisfaits et prêts à retravailler avec notre agence ou à la recommander.
Entreprendre ce projet m’a permis d’approfondir des connaissances que j’avais déjà utilisées en entreprise. J’ai pu approfondir les bonnes pratiques liées au flux de travail des développeurs. Par exemple j’ai mis en place un système qui permet de gérer les versions automatiquement. Les versions sont montées en fonction des modifications effectuées dans le code. La livraison des projets a aussi été grandement simplifiée. Le développeur n’a plus qu’à lancer une CI GitLab pour que le projet mette à jour le fichier « CHANGELOG.md » qui contient les modifications apporté par la nouvelle version puisqu’il mette en forme le projet sous la forme d’une release GitLab » avant de l’envoyer automatiquement au client après que tous les tests de qualités sont passés. Ces automatisations permettent de diminuer les erreurs en supprimant les interventions humaines qui n’ont pas d’intérêt direct. J’ai aussi pu découvrir les environnements GitLab qui ont la particularité de simplifier grandement la gestion des applications dans le cadre où l’agence gère la mise en ligne et leur maintenance. Ce fut très enrichissant techniquement pour moi, car je n’ai pas eu de date limite pour mettre en place ces derniers. J’ai donc pu prendre tout le temps nécessaire pour approfondir et maîtriser au maximum ces différentes fonctionnalités. J’ai aussi fortement évolué au niveau humain grâce au développeur qui nous a rejoint dans l’agence. Il m’a permis de mieux comprendre leurs besoins et les solutions à mettre en place pour améliorer au maximum leur expérience.
Quelles difficultés j’ai rencontrées et comment puis-je les surmonter à l’avenir ?
Durant ce projet, je n’ai pas eu de difficultés techniques, car je travaille déjà souvent avec ces technologies au sein de mon alternance au Ministère des Armées. Néanmoins, j’ai rencontré des difficultés pour la gestion du temps. Étant donné que je suis en alternance au sein du Ministère des Armées, je ne peux travailler sur le projet que le soir ou le week-end, contrairement au développeur qui travaille à mi-temps en journée sur le projet. Les synchronisations sont par conséquent plus compliquées à mettre en place. Finalement, nous avons réussi à nous caler deux créneaux de synchronisation par semaine, ce qui a grandement fluidifié le processus de réalisation de ce projet. Grâce à ces créneaux, j’ai pu adapter la solution créée durant ce projet et cadrer ce dernier pour répondre au mieux aux besoins des développeurs. Dorénavant, je dois continuer à réaliser ces deux réunions hebdomadaires pour améliorer la fluidité de toute l’agence.
Un axe majeur d’amélioration propre à mon profil est à relever. En tant qu’administrateur SRE et développeur web je n’ai jamais eu l’occasion d’apprendre ni d’utiliser directement le langage Java dans un cadre professionnel. Or ce langage reste encore très largement utilisé dans les entreprises. La gestion des dépendances Java se fait via des outils comme Maven ou Gradle. Ils sont normalement intégrés au sein des pipelines CI/CD GitLab. Je suis censé gérer ces dépendances. Il est essentiel pour moi de continuer à me former activement au langage Java et à son écosystème ainsi qu’à ses architectures applicatives (micro-services, etc.). Cette montée en compétences me permettra d’être autonome sur les pipelines où Java intervient. Je pourrais aussi améliorer la collaboration entre les équipes opérationnelles et les équipes de développement. L’anticipation des problèmes sera aussi grandement améliorée et les applications Java devrait être plus fiables en production.
Pour conclure, l’utilisation de GitLab fait partie intégrante de l’expérience des développeurs. Il s’agit d’un des outils les plus utilisés par les développeurs. Cette notion fait partie intégrante de la culture DevOps. Je l’ai découverte lors de ce projet. Mais, il s’agit d’une notion essentielle que je pourrai réutiliser en entreprise. J’ai commencé à intégrer mes nouvelles compétences au sein du Ministère des Armées. Maintenant, je souhaite approfondir certains langages de programmation. Le Java qui est majoritairement utilisé en entreprise pour approfondir la gestion de ces dépendances dans les CI GitLab et pour améliorer l’attractivité de mon profil sur le marché professionnel.