Déploiement depuis Git
La plateforme clone le dépôt, détecte le Dockerfile, construit l’image et met la version en ligne. Un commit précis peut être épinglé : c’est le retour arrière volontaire, explicite et reproductible.
Infrastructure · Produit interne
Mettre un produit en ligne
ne devrait pas être un métier à part.
DGL Deploy est la plateforme que nous avons construite pour exploiter nos propres applications : elle lit un dépôt Git, fabrique l’image, la valide, puis bascule le trafic dessus — sans interruption, sur notre serveur, sans dépendre d’un fournisseur PaaS.
Le point de départ
Entre le PaaS et le script bash, il manquait quelque chose.
Un PaaS facture chaque application et impose ses règles. Un VPS nu, à l’inverse, revient à écrire ses propres scripts de mise en ligne : on y gagne le contrôle et on y perd tout le reste — la bascule sans coupure, le retour arrière, la traçabilité, la visibilité sur ce qui tourne réellement.
Nous voulions le confort du premier sur la machine du second. DGL Deploy est cette réponse : une console unique qui connaît nos dépôts, nos domaines, nos bases de données et nos conteneurs, et qui refuse de deviner à notre place quand quelque chose est ambigu.
Ce que fait la plateforme
Du dépôt Git au trafic réel.
Six briques qui couvrent le cycle de vie complet d’une application, de sa première inspection à sa supervision quotidienne.
Bascule sans coupure
La nouvelle version démarre à côté de l’ancienne et doit prouver qu’elle répond avant de recevoir la moindre requête. Si elle échoue, le trafic n’a jamais bougé — et personne ne s’en aperçoit.
Bases de données managées
Une base PostgreSQL est provisionnée à la demande pour un projet, et son URL de connexion est injectée dans le conteneur au démarrage. Le mot de passe est scellé, il ne transite jamais en clair.
Secrets chiffrés
Identifiants Git et variables d’environnement applicatives sont chiffrés en AES-256-GCM. Ils sont déchiffrés au dernier moment, injectés par l’environnement du processus — jamais sur une ligne de commande.
Supervision de l’hôte
Charge, mémoire, disque, conteneurs, disponibilité des sites et runners d’intégration continue : l’état du serveur est relevé, historisé et tracé, sans agent externe à installer.
Routage et HTTPS
Chaque application reçoit son domaine et son entrée de routage, générée puis rechargée automatiquement. La plateforme ne touche jamais au serveur web du système — elle rend la procédure, l’opérateur l’applique.
Un déploiement, étape par étape
Ce qui se passe entre le clic et la mise en ligne.
Chaque étape est visible en direct dans la console, journal de build compris.
-
01
Inspection
Le dépôt est cloné, la pointe de branche et les derniers commits sont relevés, les Dockerfiles recensés. Un dépôt qui en contient plusieurs est signalé comme monorepo plutôt que résolu au hasard.
-
02
Construction
L’image est construite avec la configuration du dépôt — chemin du Dockerfile, cible, arguments de build. La sortie du build est diffusée en direct, ligne à ligne.
-
03
Migration
Si le projet déclare une commande de migration, elle s’exécute avant que la nouvelle version ne reçoive du trafic. Un schéma jamais en avance sur le code qui le lit.
-
04
Validation
Le conteneur démarre sur un port dédié et doit répondre à une sonde de santé. Tant qu’il n’a rien prouvé, l’ancienne version continue de servir l’intégralité du trafic.
-
05
Bascule
Le routage pointe vers la nouvelle version, l’ancienne est retirée proprement. En cas d’échec à n’importe quelle étape, le retour arrière est automatique et le service n’a jamais été interrompu.
Les décisions qui comptent
Le diable est dans les détails d’exploitation.
Une plateforme de déploiement se juge sur ce qu’elle fait quand les choses se passent mal. Voici les partis pris que nous assumons.
Ne jamais deviner en silence
Quand un dépôt contient deux Dockerfiles, la plateforme refuse de choisir : elle liste les candidats et demande. Un déploiement qui construit le mauvais service est pire qu’un déploiement qui s’arrête.
Des conteneurs volontairement bridés
Système de fichiers en lecture seule, toutes les capacités noyau retirées, jamais de root, aucun port privilégié. Une application compromise ne trouve rien à écrire et rien à élever.
Un journal qu’on n’efface pas
Chaque action privilégiée est inscrite dans un journal d’audit en ajout seul. On peut relire qui a déployé quoi, quand, et vers quelle version — y compris six mois plus tard.
Le retour arrière est un choix, pas un accident
Redéployer une version précédente se fait en épinglant son commit. C’est explicite, reproductible et visible dans l’historique — à l’opposé d’un état qui dérive sans que personne ne l’ait décidé.
Les données survivent aux mises en ligne
Les répertoires déclarés persistants sont montés dans des volumes nommés et conservés d’une version à l’autre, y compris quand le conteneur est en lecture seule.
Conteneuriser un projet qui ne l’est pas
Un dépôt sans Dockerfile n’est plus une impasse : la plateforme lit le projet, propose une conteneurisation complète, l’affiche en clair, et peut la commiter sur une branche dédiée après validation.
Sous le capot
Une architecture volontairement sobre.
Un monorepo TypeScript strict, une API, un worker, une file de travaux durable. Aucun orchestrateur à administrer.
- TypeScript
- Node.js
- React
- PostgreSQL
- Prisma
- Docker
- Nginx
- GitLab CI
- Server-Sent Events
- AES-256-GCM
File de travaux durable
Déploiements, inspections et relevés passent par une file persistée : un worker qui redémarre reprend là où il s’était arrêté, sans perdre de travail en vol.
Suivi en temps réel
La console suit l’avancement et les journaux par flux d’événements serveur — pas d’interrogation répétée, pas de page à rafraîchir.
Interface expliquée
Chaque module de la console porte son encadré d’explication en français. La documentation est dans l’outil, au moment où la question se pose.
DGL Tech Labs
Nous construisons nos outils
Nous construisons nos outils
comme nous construisons vos produits.
DGL Deploy fait tourner nos propres applications en production. C’est le même niveau d’exigence que nous appliquons aux plateformes que nous concevons pour nos clients.