Forge et intégration continue · usage courant
Agence GitLab à Nice
L'endroit où vit le code, et la chaîne qui le teste puis le déploie automatiquement.
Ce que nous en faisons
GitLab chez nos clients, concrètement
Employé sur des projets de recherche publique et sur une solution de gestion de portefeuille de brevets, avec intégration continue et suivi de production.
Les limites
Quand nous recommandons autre chose
Si votre organisation est déjà sur GitHub, la migration coûte plus qu'elle ne rapporte.
Réalisations
Nos projets menés avec GitLab
Paradigm
Plateforme d'un centre d'affaires niçois : domiciliation, courrier numérisé, messagerie et assistant.
GitLab : Intégration continue : tests, tests de bout en bout, build et déploiement.
Lire l'étude de cas ParadigmHelioneo
Plateforme d'autoconsommation collective : accords, clés de répartition, données Enedis et facturation.
GitLab : Tests, build et déploiement automatisés.
Lire l'étude de cas HelioneoSilversun — prospection
Outil de prospection B2B pour les énergies renouvelables : projets géocodés et prospects enrichis.
GitLab : Intégration et déploiement continus.
Silversun — suivi de chantier
Frise de suivi de projet photovoltaïque pour le client final, alimentée par le CRM.
GitLab : Déploiement automatisé.
Ordelya
Plateforme de pilotage de restaurants : back-office, tablettes, bornes, écrans et site.
GitLab : Intégration continue de chaque service.
Mejid & Co
Application web installable de suivi des débours pour les clients de Mejid & Co.
GitLab : Build et déploiement automatisés.
Lire l'étude de cas Mejid & CoJeu-concours Snake
Jeu-concours rétro en six niveaux, avec quiz et inscription, pour une campagne marketing d'ordinateurs portables.
GitLab : Déploiement automatisé.
Lire l'étude de cas Jeu-concours SnakeAngeles Immobilier
Site multilingue d'une agence immobilière de la Côte d'Azur : annonces, recherche et blog.
GitLab : Intégration et déploiement continus.
Lire l'étude de cas Angeles Immobilier
Méthode
Comment nous intégrons GitLab
Nous créons un groupe GitLab pour l'organisation, avec un projet par application et des rôles attribués selon les besoins : développeurs, relecteurs, personnes qui consultent seulement les tickets. La branche principale est protégée : aucune modification n'y entre sans demande de fusion relue par un second développeur et chaîne d'intégration réussie.
La chaîne suit en général quatre étapes : contrôle du style et analyse statique, tests automatiques, construction de l'image dans le registre intégré, puis déploiement. Le déploiement vers l'environnement de recette se lance seul ; celui vers la production reste une action déclenchée par une personne. Les mots de passe de déploiement sont stockés en variables masquées et protégées, lisibles uniquement par les exécutions de la branche principale. Pour les projets sensibles, les tâches tournent sur un exécuteur installé sur votre infrastructure, pas sur des machines partagées.
GitLab conserve l'historique de chaque environnement : quelle version tourne, depuis quand, déployée par qui. Nous y relions les tickets, pour que chaque mise en production renvoie aux demandes qu'elle traite. À la transmission, le dépôt contient un guide de démarrage, la description des variables attendues et la procédure pour ajouter ou retirer un membre du groupe.
Pour votre entreprise
Ce que ça change concrètement
Pour une PME, GitLab rend visible ce qui se passe sur le logiciel. Vous savez quelle version est en service, quelles demandes elle a traitées et qui l'a validée, sans devoir interroger un développeur. Une erreur qui échappe aux tests se corrige en redéployant la version précédente depuis l'historique des environnements : un geste court et documenté, plutôt qu'une réparation improvisée sur le serveur.
La sécurité y gagne aussi. Les accès aux serveurs ne sont plus copiés sur les postes des développeurs : ils restent dans la forge et ne servent qu'aux déploiements autorisés, si bien que le départ d'un collaborateur n'emporte aucun mot de passe de production. Pour les organismes publics ou les travaux liés à la propriété industrielle, réunir code, tickets et déploiements sur une instance dont vous maîtrisez l'emplacement répond aux exigences de confidentialité sans multiplier les outils. Et la personne qui reprend le projet lit la chaîne, les tickets et l'historique au même endroit, ce qui lui permet de comprendre l'évolution du logiciel avant d'y toucher.
Notre lecture
Ce que nous retenons de GitLab
GitLab, nous le proposons d’abord aux organisations qui veulent héberger leur code chez elles. L’instance auto-hébergée couvre le dépôt, les tickets, l’intégration continue et le registre d’images sur une seule machine que vous contrôlez, argument décisif dans un cadre où les sources ne doivent pas sortir du périmètre.
Les chaînes d’intégration sont décrites dans un fichier du dépôt, donc versionnées avec le code. Elles construisent une image Docker, lancent les tests dessus, et déploient exactement celle qui a passé les contrôles. Pour un projet public ou une équipe déjà installée sur GitHub, nous ne cherchons à convertir personne : le bénéfice ne couvrirait pas le coût du déménagement, et l’auto-hébergement suppose que quelqu’un assure les mises à jour.
Grille de décision
Faut-il choisir GitLab ?
GitLab ou GitHub pour héberger notre code ?
Si votre organisation est déjà sur GitHub, restez-y : la migration coûte plus qu'elle ne rapporte. GitLab prend l'avantage sur un projet neuf quand vous voulez réunir au même endroit dépôts, tickets, intégration continue, registre d'images et suivi des déploiements, ou quand le code doit rester sur vos propres serveurs. GitLab s'auto-héberge avec l'ensemble de ses fonctions, ce qui compte pour les structures publiques et les sujets sensibles. Pour un projet ouvert à une communauté, GitHub reste plus visible.
GitLab auto-hébergé ou GitLab.com ?
GitLab.com tant que rien ne vous oblige à garder le code chez vous : pas de serveur à maintenir, de mises à jour à appliquer ni de sauvegardes à surveiller. L'auto-hébergement se justifie quand une politique interne, un contrat ou la nature des travaux interdit un hébergement tiers, comme cela arrive dans la recherche publique ou en propriété industrielle. Il faut alors désigner un responsable de l'instance : un GitLab qui n'est plus mis à jour devient lui-même un point d'entrée pour un attaquant.
L'intégration continue de GitLab ou un outil séparé comme Jenkins ?
GitLab CI dans la plupart des cas. La chaîne est décrite dans un fichier du dépôt, versionnée avec le code, et ses résultats s'affichent directement sur chaque demande de fusion. Un outil séparé ajoute un serveur, des greffons et des accès à maintenir. Jenkins garde un intérêt si votre organisation en exploite déjà un avec de nombreuses chaînes en place. Pour une équipe réduite qui démarre, GitLab CI suffit et un autre développeur le reprend sans formation particulière.
Questions de clients
Ce qu'on nous demande sur GitLab
À qui appartient le code hébergé sur GitLab ?
À vous, si le projet est créé dans un espace dont vous êtes propriétaire, ce que nous recommandons dès le départ. Votre organisation détient le groupe GitLab et nos développeurs y sont invités avec des droits que vous pouvez retirer. Sur une instance auto-hébergée, le code se trouve en plus physiquement sur vos serveurs. Changer de prestataire revient alors à modifier des accès, sans transfert de dépôt ni récupération d'archives.
Qu'apporte l'intégration continue GitLab à une application déjà en production ?
Elle évite qu'une modification casse ce qui fonctionnait sans que personne ne s'en aperçoive. À chaque envoi de code, GitLab lance les tests automatiques et signale l'échec avant la mise en production. Le déploiement suit une procédure écrite dans le dépôt, au lieu de dépendre de la mémoire d'un développeur. Nous employons GitLab ainsi, avec intégration continue et suivi de production, sur une solution de gestion de portefeuille de brevets.
Un GitLab auto-hébergé demande-t-il beaucoup de maintenance ?
Davantage qu'un service en ligne, et il ne faut pas le sous-estimer. GitLab publie des mises à jour fréquentes, dont des correctifs de sécurité à appliquer rapidement, car une forge contient votre code et souvent des accès à vos serveurs. Il faut aussi sauvegarder les dépôts et la base de l'instance, surveiller l'espace disque et tester les restaurations. Si personne ne peut assurer ce suivi, GitLab.com est plus raisonnable.
Quelle différence entre l'édition gratuite de GitLab et les offres payantes ?
L'édition gratuite couvre ce dont une petite équipe a besoin : dépôts, tickets, demandes de fusion, intégration continue et registre d'images. Les offres payantes ajoutent surtout des fonctions de contrôle et de conformité, comme des règles d'approbation plus fines, des analyses de sécurité avancées ou des journaux d'audit détaillés. Nous ne recommandons un abonnement que si l'une de ces fonctions répond à une exigence identifiée, et nous le justifions alors dans le plan d'action chiffré.
Notre suivi de projet peut-il se faire directement dans GitLab ?
Oui, et c'est souvent plus simple qu'un outil séparé pour un projet logiciel. GitLab propose tickets, étiquettes, jalons et tableaux de suivi, et chaque modification de code peut renvoyer au ticket qu'elle traite. Une personne non technique peut signaler un problème ou suivre l'avancement avec un rôle limité, sans accès au code. Si votre entreprise gère déjà tous ses projets dans un autre outil, nous relions GitLab à celui-ci plutôt que d'imposer un changement.
Aller plus loin
GitLab s'inscrit dans notre Développement logiciel
Une technologie ne fait pas un projet. C'est la méthode autour qui décide du résultat : cadrage, maquettes, cycles courts, et réversibilité.
Technologies voisines
Un projet GitLab en tête ?
Le premier échange est gratuit. Nous vous dirons franchement si cette technologie est la bonne, et sinon laquelle.
Mis à jour le