CI/CD (1/5) — Le problème : tout est manuel

L’idée reçue

« Le CI/CD, c’est un outil qu’on installe (Jenkins, GitLab CI, Argo CD…). »

Non : le CI/CD est une discipline, et les outils ne sont que des exécutants. Si tu comprends les concepts — pipeline, étape, artefact, déclencheur, identifiants — changer d’outil ne sera qu’un changement d’interface. C’est cette compréhension qu’on construit ici, en réglant un vrai problème : tout ce que tu fais est manuel.

À la fin de ce module, tu sauras…

Mesurer le coût du déploiement manuel (et pourquoi il ne tient pas)
Définir pipeline, stage, artefact, trigger — indépendamment de l’outil
Vérifier que ton Jenkins (Phase 1) est prêt pour ce rôle
Connecter Jenkins à GitHub de façon standard (credential)

01Mesure ton processus manuel

Expérience 1

Compte les étapes que TU fais à chaque changement

Fais une petite modification dans SORIA Web (une ligne de HTML), puis déroule tout le chemin jusqu’à la production, en notant chaque commande :

Manipule

cd ~/soria-web
# 1. modifier le code
git add . &amp;&amp; git commit -m "MàJ page d'accueil" &amp;&amp; git push
# 2. construire l'image
docker build -t harbor.mondomaine.fr/soria/soria-web:2.1 .
# 3. pousser vers Harbor
docker push harbor.mondomaine.fr/soria/soria-web:2.1
# 4. déployer sur le cluster
helm upgrade demo-release ./demo-chart -n lab-soria --set image.tag=2.1

Quatre blocs, une dizaine de commandes, plusieurs minutes — à chaque changement. Et à chaque étape, un risque d’erreur humaine : oublier le push, se tromper de tag, sauter le scan…

Comprends pourquoi le manuel ne tient pas

Dix changements par semaine = des dizaines de séquences manuelles, chacune pouvant diverger (tag oublié, étape sautée, ordre inversé). Le déploiement devient irrégulier et risqué — exactement ce que la production ne tolère pas. La réponse n’est pas « faire plus attention », c’est faire exécuter la séquence par une machine, à l’identique, à chaque fois.

02Le vocabulaire universel du CI/CD

Avant de toucher Jenkins, fixons les concepts — ils sont identiques dans Jenkins, GitLab CI, GitHub Actions ou Argo CD. Seule l’interface change.

Concept	Définition (indépendante de l’outil)	Dans ton projet
Pipeline	la séquence automatisée d’étapes, décrite dans un fichier versionné	ce que tu viens de faire à la main
Stage	une étape du pipeline, avec un rôle précis	build · scan · push · deploy
Artefact	le produit d’un stage, passé au suivant	ton image Docker taguée
Trigger	l’événement qui déclenche le pipeline	un `git push`
Credential	une identité machine stockée de façon sûre	robot Harbor, clé GitHub, kubeconfig

Comprends CI vs CD, en une phrase chacun

CI (intégration continue) : à chaque changement de code, construire et vérifier automatiquement — produire un artefact fiable. CD (déploiement continu) : amener automatiquement cet artefact jusqu’à l’environnement d’exécution. Retiens la chaîne, pas l’outil : code → build → artefact → registre → déploiement. Demain sur Argo CD ou GitLab CI, cette chaîne sera exactement la même.

03Ton Jenkins est déjà là

Expérience 2

Retrouver le serveur installé en Phase 1

Le Jenkins que tu as installé en Phase 1 — comme véhicule d’apprentissage Linux — prend enfin son vrai rôle. Vérifie qu’il est opérationnel et qu’il dispose des outils dont le pipeline aura besoin :

Manipule

systemctl status jenkins --no-pager | head -n 3
docker --version
git --version

Observe

● jenkins.service - Jenkins Continuous Integration Server
   Active: active (running)
Docker version 2x.x.x
git version 2.x.x

Jenkins tourne (HTTPS via HAProxy depuis la Phase 4 : https://jenkins.mondomaine.fr). Docker et Git sont présents sur la machine — le pipeline en aura besoin pour builder et cloner.

Si Docker manque sur la VM Jenkins, installe-le comme en Phase 3 (dépôt officiel), et ajoute l’utilisateur jenkins au groupe docker : sudo usermod -aG docker jenkins && sudo systemctl restart jenkins. Le pipeline s’exécute sous cet utilisateur.

Comprends pourquoi Jenkins a besoin de ces outils

Un serveur CI/CD n’a rien de magique : il exécute des commandes — les mêmes que toi. Pour cloner, il lui faut Git ; pour builder, Docker ; pour déployer, Helm (on l’installera au module CD). Le pipeline n’est que ta séquence manuelle, écrite pour être rejouée par une machine.

04Connecter Jenkins à GitHub

Expérience 3

Une identité machine pour cloner le dépôt

Pour cloner ton dépôt (privé), Jenkins a besoin d’une identité — exactement comme mgmt en Phase 4.2. Sur la VM Jenkins, génère une clé dédiée :

Manipule

sudo -u jenkins ssh-keygen -t ed25519 -C "jenkins-soria" -f /var/lib/jenkins/.ssh/id_ed25519 -N ""
sudo -u jenkins cat /var/lib/jenkins/.ssh/id_ed25519.pub

Ajoute cette clé publique dans GitHub (Settings → SSH keys, ou mieux : Deploy key du dépôt, en lecture seule). Puis enregistre la clé privée dans Jenkins :

Jenkins → Manage Jenkins → Credentials → (global) → Add Credentials
Kind : SSH Username with private key
ID : github-soria-ssh · Username : git
Private key : colle le contenu de id_ed25519

Vérifie la connexion depuis la VM :

Manipule

sudo -u jenkins ssh -T git@github.com

Observe

Hi ton-compte! You've successfully authenticated ...

Jenkins possède désormais sa propre identité GitHub, stockée comme credential — jamais en clair dans un script.

Comprends le concept credential, au-delà de Jenkins

Un credential store est un coffre où l’outil CI garde les identités machines (clés SSH, tokens, fichiers secrets), référencées par un ID dans les pipelines — jamais copiées en clair. Tous les outils CI/CD ont l’équivalent : « Variables/Secrets » dans GitLab CI, « Secrets » dans GitHub Actions. Même principe de moindre privilège que le robot Harbor : une identité par machine, limitée à son besoin (une Deploy key en lecture seule suffit pour cloner).

✓Ce que tu retiens

Le déploiement manuel ne tient pas à l’échelle : la réponse est le pipeline — ta séquence, exécutée par une machine. Le vocabulaire (pipeline, stage, artefact, trigger, credential) est universel : Jenkins n’est qu’un exécutant parmi d’autres. Ton Jenkins de Phase 1 est prêt, outillé (Git, Docker), et connecté à GitHub par une identité machine propre.

Mini-projet

Prépare le terrain de l’automatisation

À faire

Déroule une dernière fois le chemin manuel complet (code → build → push → deploy) et chronomètre-le.
Vérifie Jenkins, Docker et Git sur la VM Jenkins (et le groupe docker pour l’utilisateur jenkins).
Crée la clé SSH de Jenkins et enregistre-la comme credential github-soria-ssh.
Prouve l’authentification GitHub depuis la VM Jenkins.
Documente dans BookStack les 5 concepts universels avec tes propres mots.

Fil rouge — Jenkins peut maintenant lire ton code. Au module suivant, on écrit le premier pipeline : à chaque commit, Jenkins construira ton image et la poussera dans Harbor — la moitié CI de la chaîne.

?Auto-évaluation

1. Qu’est-ce qu’un pipeline, indépendamment de l’outil ?

Une séquence automatisée d’étapes (stages), décrite dans un fichier versionné, exécutée par une machine à chaque déclencheur.

2. Quelle est la différence entre CI et CD ?

CI : construire et vérifier automatiquement à chaque changement (produire un artefact fiable). CD : amener automatiquement cet artefact jusqu’à l’environnement d’exécution.

3. Pourquoi stocker les identités dans un credential store ?

Pour ne jamais mettre de secrets en clair dans les scripts : le pipeline les référence par ID, et chaque identité machine reste limitée à son besoin.