Pilotez tous vos déploiements GitLab depuis un seul écran.
Deployer regroupe vos dépôts GitLab en un espace de livraison : une tuile par environnement, le déploiement d’un environnement à l’autre en un geste, et les notes de version calculées depuis les commits.
Pour les équipes GitLab, en SaaS ou on-premise.
Une release multi-dépôts ne vit dans aucun écran de GitLab.
- Un onglet par dépôt pour savoir ce qui tourne en préproduction.
- Une merge request créée à la main, par projet et par environnement.
- Un dépôt oublié, et la version part incomplète, sans que rien ne le signale.
- Une tuile par environnement, dans l’ordre de la chaîne de déploiement.
- Les merge requests ouvertes vers toutes les cibles en un geste.
- Une version incomplète est détectée et bloquée avant la mise en service.
Le produit, tel qu’il est.
Sept écrans pour couvrir toute la livraison.
Ce qui tourne sur chaque environnement, et ce qui est prêt à être déployé, avec le pipeline de chaque projet en une ligne.
Les merge requests d’une même issue, regroupées sur tous les dépôts. L’issue se valide quand tout est fusionnable, jamais à moitié.
La branche d’essai qui porte la principale et les fonctionnalités prêtes, reconstruite à chaque changement, pour essayer avant de fusionner.
D’une issue GitLab aux merge requests de hotfix : Deployer retrouve les commits et ouvre les branches sur chaque projet concerné.
Un tag posé sur tous les dépôts d’un geste, son pipeline suivi jusqu’au bout.
Branches cibles, sources autorisées, variables, actions à lancer avant une mise en service : tout se déclare ici, une fois.
Cinq rôles, du lecteur au product owner. Le token GitLab reste verrouillé côté serveur.
Par branche ou par version : Deployer gère les deux.
- Déployer, c’est pousser : de master vers test, puis preprod, puis prod.
- Chaque environnement déclare les branches autorisées à y entrer.
- Le tag de version est posé automatiquement au moment du déploiement.
- On construit une fois, au tag : la CI est séparée du déploiement.
- Le même artefact est déployé d’un environnement à l’autre, à l’identique.
- Une version incomplète, avec un dépôt sans le tag, ne part jamais en service.
Le mode se choisit à la création de l’espace et ne change plus ensuite : tout l’historique de livraison en dépend.
Le product owner valide les fonctionnalités. Le développeur corrige la production.
Une fonctionnalité touche souvent plusieurs dépôts. Deployer regroupe ses merge requests sous l’issue et lit le verdict de GitLab pour chacune.
Un bug en prod, une issue GitLab. Deployer prépare le hotfix de bout en bout. Vous validez avant que quoi que ce soit ne soit écrit dans GitLab.
Essayez une fonctionnalité avant de la fusionner.
Deployer assemble la branche principale et les fonctionnalités prêtes en une branche d’essai, reconstruite à chaque changement. Le product owner essaie la fonctionnalité entière sur l’environnement de développement, puis la fusionne depuis l’écran Fonctionnalités.
- Une fonctionnalité en conflit dans un seul dépôt est écartée de tous : rien ne part à moitié.
- Reconstruction automatique à chaque changement, CI verte exigée ; un gel fige la branche pendant l’essai.
- Chaque écartée dit pourquoi, et le développeur est prévenu sur sa merge request.
La branche assemblée ne peut jamais être déployée : ni source ni cible d’une version ou d’un hotfix. Elle sert à essayer, jamais à livrer.
La note de version se calcule. Puis elle se rédige.
Douze dépôts, des dizaines de tickets, plusieurs équipes : Deployer compare les refs et produit la note en une passe : une ligne par ticket, rangée par équipe, exportable en Markdown ou Excel.
- Une ligne par ticket, avec ses commits et ses projets.
- Les commits sans référence de ticket sont comptés, pas cachés.
- Export Markdown ou Excel, prêt à diffuser.
- L’IA écarte le bruit technique et rédige pour qui va lire : technique, produit ou client.
- Une douzaine d’entrées lisibles, pas quarante lignes de commits.
- La note calculée reste dessous, comme référence.
La note rédigée peut en dire moins que la note calculée, jamais autre chose : une référence de ticket inventée bloque l’enregistrement.
Deployer se branche sur votre GitLab, il ne le remplace pas.
Un serveur qui décide, votre GitLab qui exécute. Deployer ne fait aucun Git : quand il faut cloner et pousser, c’est un projet GitLab dédié, l’orchestrateur, qui s’en charge chez vous.
SaaS ou chez vous. Client de l’API GitLab : il ne fait pas de Git, il n’a pas de dépôt. Le token de l’espace reste sur le serveur, jamais dans le navigateur.
- lit et écrit : branches, MR, tags
- webhooks : ce qui bouge chez vous
- déclenche un pipeline : avec le manifeste
- rapport : ce qui a été assemblé
Vos dépôts : branches, merge requests, pipelines, tags. Ce sont eux que la grille affiche.
La référence qui relie les merge requests d’une même fonctionnalité, sur tous les dépôts.
- pousse la branche assemblée
Un projet GitLab dédié, monté en deux minutes depuis le gabarit fourni. Il clone, simule les fusions, réconcilie, et pousse la branche assemblée. Le token de clonage vit ici, en variable masquée, posée par Deployer.
Rien à installer dans vos seize dépôts : un seul projet à monter, depuis un gabarit identique pour tout le monde. L’orchestrateur n’est pas un projet lié : il n’apparaît ni dans la grille des déploiements, ni parmi les dépôts à assembler.
Trois étapes pour un espace exploitable.
Parlons de votre chaîne de livraison.
Une démonstration de trente minutes, sur vos dépôts, sans installation préalable.