04 / Collaboration & déploiement
GitLab / CI-CD
Du travail en groupe à la mise en ligne.
Une infrastructure GitLab personnelle préparée pour un projet étudiant en groupe. Le sujet est décalé : un site autour de « la pire voiture possible ».
01 / LE BESOIN
Partager du code, puis pouvoir le livrer.
Pour le projet étudiant autour de « la pire voiture possible », l’objectif est de travailler par branches et relectures, puis d’arriver à un déploiement sans accès SSH pour les camarades.
02 / LA CONSTRUCTION
La destination est tracée. Pas encore automatisée.
GitLab est installé dans l’environnement privé. Le schéma ci-dessous décrit le workflow visé : il ne représente ni une pipeline exécutée ni des jobs déjà réussis.
- Développeur
- Branche
- Commit / push
- GitLab
- Merge requestRelire
- TestsVérifier
- BuildCréer l’image
- DéploiementLivrer
03 / LES CHOIX TECHNIQUES
Construire la chaîne par étapes.
Des contributions relues
Branches et merge requests font partie du workflow prévu. L’installation GitLab seule ne signifie pas que le projet de groupe est déjà configuré.
Des builds hors de l’infrastructure personnelle
Le plan prévoit un runner isolé, sans socket Docker ni secrets du serveur principal accessibles au code étudiant.
Déployer une version identifiable
La cible est une image liée à une version du code, des tests préalables et un retour à la version précédente si le déploiement échoue.
04 / ÉTAT & PERSPECTIVES
GitLab installé ; la livraison reste à construire.
Le relevé du 6 septembre 2026 ne comptait aucun projet ni runner enregistré. Les étapes de collaboration, de tests, de build et de déploiement restent donc présentées comme prévues.
La suite. Configurer un projet témoin et un runner isolé pour les tests avant d’ajouter le build puis le déploiement.