Discussion :

[G-Orwell]

Hello,

J'ai lu plusieurs tuto en francais et regardé plusieurs video et malgré tout ca il y a des choses que je ne comprends pas sur le fonctionnement de Git en général, des gitlab runner et des pipelines.

1) Déjà est-ce que le runner c'est un container Docker ou est-ce juste l'agent installé sur le serveur (par exemple le serveur web qui va recevoir une nouvelle livraison) et qui scrute le repo git (donc l'origine) en l'attente d'un push ?

Si c'est un container Docker où s'excute t'il ? Chez gitlab.com ou sur le serveur qui va recevoir la livraison ?

2) J'ai lu que le "script" ou les stages contenu dans le .gitlab-ci.yml s'éxécutent à chaque commit de code. Est-ce que ça veut dire que Gitlab indique à la machine d'où est partie le commit d’exécuter le contenu du .gitlab-ci.yml ?

3) Qu'est-ce qu'on appelle pipeline ? Est-ce un Job ? Un ensemble de Job strictement défini ? L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml ?

4) Si j'ai bien compris il ne peut y avoir qu'un seul .gitlab-ci-yml par branche git ?
Donc si j'ai 5 environnements différents (par ex LOCAL, TEST, DEV, STAGING, PROD) et que je veux un déploiement entièrement automatique et changer quelques détails en fonctione de l'environnement jusqu'en STAGING il faut que j'organise mon projet en 5 branches différentes avec chacune un fichier .gitlab-ci-yml ?

5) Qu'est-ce qui se passe à l'issue d'une merge request si par exemple je veux merger la branche STAGING vers la branche PROD ?
Est-ce que ma branche STAGING continue d'exister et son .gitlab-ci-yml reste inchangé? Ou disparait elle ? En d'autre termes est-ce qu'une MR c'est seulement le remplacement du contenu de ma branche PROD par celui de la branche STAGING par une sorte de rm -rf prod/
et cp -R STAGING/ PROD/ ?

Bon comme vous le voyez jj'ai pas tout compris et c'est un sacré sac de noeud dans ma tête donc svp n'hesitez pas à détailler vos explications.
Si y 'en a qui ont des schémas, des blogs ou des videos qui résument tout ça je suis preneur.

Georges

[Marco46]

1) Déjà est-ce que le runner c'est un container Docker [...] et qui scrute le repo git (donc l'origine) en l'attente d'un push ?

C'est l'agent.

ou est-ce juste l'agent installé sur le serveur (par exemple le serveur web qui va recevoir une nouvelle livraison)

Ça ne devrait pas être entremêlé.

Ta CI est une chose, tes environnements en sont une autre, bien distinctes l'une de l'autre.

Ta pipeline ne s'exécute pas dans un environnement, c'est différent. Tu as besoin d'une image docker comme support mais tu ne déploies pas à cet endroit, tu vas cloner ton projet, checkout la bonne ref (branche ou tag), tu vas exécuter ton linter, tes tests unitaires, tu vas build ton livrable, le packager, pousser le package dans ton registre, etc ...

2) J'ai lu que le "script" ou les stages contenu dans le .gitlab-ci.yml s'éxécutent à chaque commit de code. Est-ce que ça veut dire que Gitlab indique à la machine d'où est partie le commit d’exécuter le contenu du .gitlab-ci.yml ?

Ça dépend comment tu configures tes stages.

Généralement on exécute une pipeline à l'ouverture d'une merge request, pas nécessairement au push.

3) Qu'est-ce qu'on appelle pipeline ?

C'est la modélisation par GitLab d'une pipeline DevOps.

3) Est-ce un Job ?

Non. Un job c'est une étape de ta pipeline. Un stage c'est pour définir quand et comment tu l'exécutes. Cf https://docs.gitlab.com/ee/ci/pipelines.html

3) Un ensemble de Job strictement défini ?

Oui en quelques sortes.

3) L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml ?

Selon la configuration du déclenchement. Sur une pipeline donnée tu peux avoir différents stages exécutés en fonction du déclencher (merge request ouverte, merge request mergé, création d'un tag, etc ...)

4) Si j'ai bien compris il ne peut y avoir qu'un seul .gitlab-ci-yml par branche git ?

Ce n'est pas de cette manière qu'il faut le comprendre. Une branche n'est pas un container, c'est un pointeur sur un commit de l'arbre des commits (ton dépôt) permettant d'ajouter de nouveaux commits.

Donc si j'ai 5 environnements différents (par ex LOCAL, TEST, DEV, STAGING, PROD) et que je veux un déploiement entièrement automatique et changer quelques détails en fonctione de l'environnement jusqu'en STAGING il faut que j'organise mon projet en 5 branches différentes avec chacune un fichier .gitlab-ci-yml ?

Surtout pas. Si tu as différentes versions de ta config tu as différentes pipelines.

Une branche peut représenter un environnement mais cet environnement n'est pas porté par GitLab.

Une pipeline abouti à la création d'un package contenant le livrable. Ce package est rangé dans un registre et c'est depuis ce registre qu'on déploie. Tu peux parfaitement avoir un job de delivery qui va prendre le package correspondant à ton tag pour le déployer dans un environnement. C'est même le but

Concernant les configs de ton livrable dans tes environnements la bonne pratique est de versionner la config de ton livrable pour chaque environnement dans ton dépôt. Notes que je ne parle pas de la config de l'environnement lui-même (pour ça voir IaaS : puppet, ansible etc ...) Donc tu dois avoir toutes les confs de ton appli pour chaque environnement dans le commit qui sert de base à la génération de ton livrable.

Est-ce que ma branche STAGING continue d'exister et son .gitlab-ci-yml reste inchangé? Ou disparait elle ? En d'autre termes est-ce qu'une MR c'est seulement le remplacement du contenu de ma branche PROD par celui de la branche STAGING par une sorte de rm -rf prod/
et cp -R STAGING/ PROD/ ?

C'est hors de propos. Ce n'est pas une branche que tu déploies mais un livrable indexé dans un registre.

Bon comme vous le voyez jj'ai pas tout compris et c'est un sacré sac de noeud dans ma tête donc svp n'hesitez pas à détailler vos explications.

La première étape avant de se lancer dans GitLab c'est de bien maîtriser Git. Tu devrais commencer par là.

Tips : On ne génère pas un livrable depuis une branche mais depuis un tag (un commit précis). Une branche peut représenter un environnement pour y faire du continuous deployment mais c'est le stade ultime de l'évolution DevOps. Il faut pas bruler les étapes et y aller petit à petit. Commence par essayer de faire du Continuous Delivery c'est déjà assez compliqué comme ça à faire proprement.

Si y 'en a qui ont des schémas, des blogs ou des videos qui résument tout ça je suis preneur.

Le lien que j'ai donné ci-dessus est un bon point de départ en français.

Si l'anglais ne te pose pas de problème tu as les travaux de Jez Humble et Martin Fowler :

Et la version littéraire : https://martinfowler.com/books/continuousDelivery.html

Le chapitre 14 sur les SCM est largement obsolète car centré sur subversion mais on se prend une petite dose d'histoire qui ne fait pas de mal, pour le reste il n'y a pas une virgule à changer ça fait partie des must read. Gros morceau par contre !

[G-Orwell]

Merci infiniment pour cette réponse très riche.

A la lecture de tes explications, j'ai plusieurs questions.

Ça ne devrait pas être entremêlé.

Ta CI est une chose, tes environnements en sont une autre, bien distinctes l'une de l'autre.

Ta pipeline ne s'exécute pas dans un environnement, c'est différent. Tu as besoin d'une image docker comme support mais tu ne déploies pas à cet endroit, tu vas cloner ton projet, checkout la bonne ref (branche ou tag), tu vas exécuter ton linter, tes tests unitaires, tu vas build ton livrable, le packager, pousser le package dans ton registre, etc ...

Ok, ca pourrait donc être une machine dédiée à la CI/CD , comme si par exemple je n'utilisais gitlab que comme repos git et Jenkins installé dans une VM comme outil pour faire les tests et les builds ?

Concernant les configs de ton livrable dans tes environnements la bonne pratique est de versionner la config de ton livrable pour chaque environnement dans ton dépôt. Notes que je ne parle pas de la config de l'environnement lui-même (pour ça voir IaaS : puppet, ansible etc ...) Donc tu dois avoir toutes les confs de ton appli pour chaque environnement dans le commit qui sert de base à la génération de ton livrable.

Tu veux dire pas la config infra mais la config appli comme le web.xml ou web.config ?

Tips : On ne génère pas un livrable depuis une branche mais depuis un tag (un commit précis). Une branche peut représenter un environnement pour y faire du continuous deployment mais c'est le stade ultime de l'évolution DevOps. Il faut pas bruler les étapes et y aller petit à petit. Commence par essayer de faire du Continuous Delivery c'est déjà assez compliqué comme ça à faire proprement.

Quelle différence y a t'il entre continus delivery et continus deployement? Jusqu'ici pour moi c'était deux termes synonymes


Merci

[Marco46]

Ok, ca pourrait donc être une machine dédiée à la CI/CD , comme si par exemple je n'utilisais gitlab que comme repos git et Jenkins installé dans une VM comme outil pour faire les tests et les builds ?

Oui c'est très exactement ça. Jenkins est inutile avec GitLabCI.

Notes qu'il y a un service de registre aussi avec GitLab donc tu peux même te passer éventuellement d'un Nexus / Artifactory.

Après je ne connais pas le détail des offres commerciales de GitLab, les services proposés même dans la version installable libre doivent grandement varier en fonction du tarif.

Tu veux dire pas la config infra mais la config appli comme le web.xml ou web.config ?

Je ne connais pas ces fichiers (Java ?) je fais surtout du JavaScript. S'ils décrivent comment ton serveur web se comporte ça relève de l'infra (et encore à confirmer avec un DevOps J2EE), si c'est la config de l'application elle-même (urls des endpoints, niveau de log, etc ...) alors c'est ça.

Quelle différence y a t'il entre continus delivery et continus deployement? Jusqu'ici pour moi c'était deux termes synonymes

Dans les deux cas chaque commit mergé est déployable. Il n'y a jamais d'état instable de l'app. Ça compile tout le temps, ça build tout le temps, les tests passent tout le temps. C'est tout le temps stable et prêt à être déployé.

Sur cette base là :

- continuous delivery = je peux déployer à chaque commit mergé
- continuous deployment = je déploie à chaque commit mergé

La différence semble minime mais pourtant elle est de taille.

Dans le cas du continuous deployment tout est automatisé, il n'y a pas de décision humaine donc zéro QA humaine. En théorie je vais en prod si tout est OK.

Dans le cas du continuous delivery je décide quand je veux déployer et donc je décide du périmètre puisque je vais du coup déployer une série de commit.

Après c'est du tableau général, il y a autant de configuration possibles qu'il y a d'organisation et de manière de travailler. Normalement le continuous deployment désigne le fait d'aller en prod mais certains l'utilise aussi sur des environnements largement en amont, par exemple sur un environnement de dev qui précède la QA.

Donc tu peux avoir par exemple :

- un environnement de dev sur lequel on build / déploie à chaque commit mergé sur une branche dédiée (develop par exemple) là on est donc en continuous deployment
- un environnement de recette sur lequel on build / déploie lors des merge vers la branche dédiée représentant cet environnement (release), là c'est du continuous delivery puisqu'on merge manuellement
- on peut aussi trigger les déploiements non pas sur la base de branches représentant les environnements mais via des jobs de CI en leur donnant un tag + un environnement.

Etc ...