Salut Xavki, J'avoue que ta vidéo me rassure, même si ce n'est pas la vision de tous. Chez mon client actuel, c'est ce qu'on avait mis en place, un gitlab-ci qui fait tout, et de manière standardiser pour tout type de projet, les autres n'avaient plus qu'a inclure le fichier, mettre 2/3 variables (minimal), et bim ça déploie et c'est fonctionnel. Avec bien-sur toujours la possibilité overwrité les jobs au besoin. Cependant, le client à décidé de faire un audit du ci/cd par une boite externe, et eux leurs préco, c'est de jarté ceci, pour donner la main et la connaissance directement aux différentes équipes. Je trouvais ce choix totalement débile, mais plusieurs personnes me disaient que c'était justement ça la philosophie devops, chacun fait son truc dans son coin. Ca me rassure que tu partages mon avis.
Hello effectivement ce n'est pas forcément une grande idée. Après cela peut dépendre de l'organisation des équipes et du nombre de services. Néanmoins quand je vois ça je n'aime pas trop c'est comme si dans une boîte chaque équipe de dev concevait une librairie pour faire la même chose. Après le devops on peut lui faire dire n'importe quoi et certaines sociétés ou certaines personnes l'utilisent pour faire tourner leur business, vendre de la formation, réécrire des choses qui sont déjà efficaces et fonctionnelles. Bon courage à toi. Ce n'est que mon retour d'expérience 😉
Il faut bien s'adapter au contexte, mais en effet, pourquoi faire plusieurs pipelines quant on peut templatiser, définir un standard. Cela diminue la maintenance du code de déploiement, le temps gagner permet d'investir dans les tests du ci lui même etc... Enfin, c'est comme ca que je le vois aussi. Gitlab-ci, d'ailleurs le fait très bien avec les includes, cela permet d'avoir un repos de ci de template, les dev pioche dedans et surcharge avec d'éventuelle spécificité.
perso je trouve que la remarque comme quoi les devs doivent être autonomes / maitriser le déploiement de leur code est pertinente par contre pas besoin de tout jeter pour autant : les devs doivent simplement comprendre comment ça fonctionne et être capables de faire évoluer le template commun ça demande un effort dans la maintenance et surtout la collaboration - pour moi c'est ça le devops tout est dans le "bim ça déploie" : es-ce qu'ils comprennent et maitrisent ce qu'ils font ? peuvent facilement modifier / personnaliser le process ? ou sont-ils dépendants d'une autre équipe qui a la maitrise (voire la compréhension) exclusive des templates ? auquel cas on retombe dans la dichotomie Dev vs Ops 😅 car j'ai un contre exemple en tant que dev : s'être fait imposer un framework commun de déploiement très obscur (du python qui appelle du bash qui configure du systemd qui lance du SALT qui rappelle du python...) développé dans son coin par un sysadmin... "pas de collaboration pas de devops" 😄
Salut Xavki, j'aimerai pouvoir commencer a faire du déploiement, de l'administration ..., je suis novice et je ne sais pas par quelle playlist commencer. Je dois commencer par apprendre Docker ou Ansible ?, j'ai bien compris aussi l'importance d'avoir une bonne connaissance du système (Linux) que j'étudie en parallèle , mais concrètement, pour faire du déploiement et mieux comprendre l'administration tu me conseil quoi comme trame d'apprentissage ? Je voulais commencer par cette playlist : ANSIBLE : DÉBUTANT ET PLUS | TUTOS FR , c'est une bonne idée ? Merci pour les vidéos .
Salut pour flux le principal se passe au niveau de helm. Il faut tenter d'avoir une seule chart suffisamment universelle pour gérer tout ses déploiements (c'est ce que j'utilise à mon taff). Du coup tu n'en maintiens que une seule et ta helmrelease est ton moyen déclaratif pour l'utiliser. C'est relativement simple à faire de ce côté. Après en amont tu peux suivant le support un build d'image docker, tests etc centralisé soit via gitlab soit via Jenkins ou autres. ++
Merci pour ta réponse :) @@xavki ahhh donc un values.yaml et encrypted secrets par repo j'imagine Et dans un repo infra tu mets ta chart et tes manifestes flux?
C'est à peu près cela. Plutôt si tu fais du helm tu as un dépôt avec toutes tes helm release que flux va synchroniser. Donc après tu organisé ton cluster en namespace avec un répertoire par namespace et ensuite dans chaque répertoire tes Helm release
Vidéo très intéressante comme d'habitude. Je suis à la recherche d'un cheat sheet décrivant les différents stages d'une pipeline CI/CD ainsi que les applications utilisées pendant ces stages. J'ai beau chercher depuis plusieurs mois mais je ne trouve rien de très précis.
Je n'en connais pas. J'ai la playlist devenir devops qui peut t'aguiller mais c'est technique. Après pour une même étape tu trouveras différents outils valables aussi.
On commence à faire des pipelines et le sujet de factorisation semble effectivement important à mener. De notre coté on évite de faire de l'environnement branching pour avoir en plus des branches par environnement. Penses tu qu'il failles faire un projet de ci cd par grand sujet ? Type 1 maven / 1 python etc... ou un projet global qui prendrait en paramètre la nature meme du projet à mener ? Hâte d'écouter la playlist v2 sur le sujet
C'est ce que je tente de guider via cette vidéo, il faut tenter d'avoir un seul et unique pipeline. Après si cela rend le code et la maintenance du pipeline trop compliqué il faut splitter. On peut très bien avoir un pipeline qui va gérer du java et du python, go etc. Faut trouver le bon équilibre suivant les usages. ++
@@xavki hello oui je suis parti sur du split du coup. Merci. Domaine par domaine c'est plus simple sur la construction et j'espère la maintenance, les tests et l'appropriation. Surtout quand peu de personnes maîtrisent les subtilités du code gitlab-ci.
Des fois, le client veut faire du Devops sans méthode Devops ... du coup on est pris en étau.🤔 On fini par faire des chaines CI-CD de chaine de CI-CD. 🤨 Merci pour le REX.
Hello. Il faut utiliser les trigger et trigger un projet unique dédié au pipeline. Perso je préfère Jenkins pour cet aspect. Regarde la playlist gitlab qui pourra peut-être te donner des idées.
Merci pour ton REX, c'est super intéressant.
Avec plaisir quand on a appris des choses autant les partager 😉
Salut Xavki,
J'avoue que ta vidéo me rassure, même si ce n'est pas la vision de tous.
Chez mon client actuel, c'est ce qu'on avait mis en place, un gitlab-ci qui fait tout, et de manière standardiser pour tout type de projet, les autres n'avaient plus qu'a inclure le fichier, mettre 2/3 variables (minimal), et bim ça déploie et c'est fonctionnel. Avec bien-sur toujours la possibilité overwrité les jobs au besoin.
Cependant, le client à décidé de faire un audit du ci/cd par une boite externe, et eux leurs préco, c'est de jarté ceci, pour donner la main et la connaissance directement aux différentes équipes. Je trouvais ce choix totalement débile, mais plusieurs personnes me disaient que c'était justement ça la philosophie devops, chacun fait son truc dans son coin. Ca me rassure que tu partages mon avis.
Hello effectivement ce n'est pas forcément une grande idée. Après cela peut dépendre de l'organisation des équipes et du nombre de services. Néanmoins quand je vois ça je n'aime pas trop c'est comme si dans une boîte chaque équipe de dev concevait une librairie pour faire la même chose.
Après le devops on peut lui faire dire n'importe quoi et certaines sociétés ou certaines personnes l'utilisent pour faire tourner leur business, vendre de la formation, réécrire des choses qui sont déjà efficaces et fonctionnelles.
Bon courage à toi. Ce n'est que mon retour d'expérience 😉
Il faut bien s'adapter au contexte, mais en effet, pourquoi faire plusieurs pipelines quant on peut templatiser, définir un standard. Cela diminue la maintenance du code de déploiement, le temps gagner permet d'investir dans les tests du ci lui même etc...
Enfin, c'est comme ca que je le vois aussi.
Gitlab-ci, d'ailleurs le fait très bien avec les includes, cela permet d'avoir un repos de ci de template, les dev pioche dedans et surcharge avec d'éventuelle spécificité.
perso je trouve que la remarque comme quoi les devs doivent être autonomes / maitriser le déploiement de leur code est pertinente
par contre pas besoin de tout jeter pour autant : les devs doivent simplement comprendre comment ça fonctionne et être capables de faire évoluer le template commun
ça demande un effort dans la maintenance et surtout la collaboration - pour moi c'est ça le devops
tout est dans le "bim ça déploie" : es-ce qu'ils comprennent et maitrisent ce qu'ils font ? peuvent facilement modifier / personnaliser le process ? ou sont-ils dépendants d'une autre équipe qui a la maitrise (voire la compréhension) exclusive des templates ? auquel cas on retombe dans la dichotomie Dev vs Ops 😅
car j'ai un contre exemple en tant que dev : s'être fait imposer un framework commun de déploiement très obscur (du python qui appelle du bash qui configure du systemd qui lance du SALT qui rappelle du python...) développé dans son coin par un sysadmin... "pas de collaboration pas de devops" 😄
Salut Xavki, j'aimerai pouvoir commencer a faire du déploiement, de l'administration ..., je suis novice et je ne sais pas par quelle playlist commencer. Je dois commencer par apprendre Docker ou Ansible ?, j'ai bien compris aussi l'importance d'avoir une bonne connaissance du système (Linux) que j'étudie en parallèle , mais concrètement, pour faire du déploiement et mieux comprendre l'administration tu me conseil quoi comme trame d'apprentissage ? Je voulais commencer par cette playlist : ANSIBLE : DÉBUTANT ET PLUS | TUTOS FR , c'est une bonne idée ? Merci pour les vidéos .
Hello oui commence plutôt par ansible 😉
Super vidéo :)
Tu as des exemples concrets avec argo ou flux sur comment gérer ca?
De la doc peut-être ?
Salut pour flux le principal se passe au niveau de helm. Il faut tenter d'avoir une seule chart suffisamment universelle pour gérer tout ses déploiements (c'est ce que j'utilise à mon taff). Du coup tu n'en maintiens que une seule et ta helmrelease est ton moyen déclaratif pour l'utiliser. C'est relativement simple à faire de ce côté. Après en amont tu peux suivant le support un build d'image docker, tests etc centralisé soit via gitlab soit via Jenkins ou autres. ++
Merci pour ta réponse :)
@@xavki ahhh donc un values.yaml et encrypted secrets par repo j'imagine
Et dans un repo infra tu mets ta chart et tes manifestes flux?
C'est à peu près cela. Plutôt si tu fais du helm tu as un dépôt avec toutes tes helm release que flux va synchroniser. Donc après tu organisé ton cluster en namespace avec un répertoire par namespace et ensuite dans chaque répertoire tes Helm release
Vidéo très intéressante comme d'habitude.
Je suis à la recherche d'un cheat sheet décrivant les différents stages d'une pipeline CI/CD ainsi que les applications utilisées pendant ces stages.
J'ai beau chercher depuis plusieurs mois mais je ne trouve rien de très précis.
Je n'en connais pas. J'ai la playlist devenir devops qui peut t'aguiller mais c'est technique. Après pour une même étape tu trouveras différents outils valables aussi.
On commence à faire des pipelines et le sujet de factorisation semble effectivement important à mener. De notre coté on évite de faire de l'environnement branching pour avoir en plus des branches par environnement. Penses tu qu'il failles faire un projet de ci cd par grand sujet ? Type 1 maven / 1 python etc... ou un projet global qui prendrait en paramètre la nature meme du projet à mener ? Hâte d'écouter la playlist v2 sur le sujet
C'est ce que je tente de guider via cette vidéo, il faut tenter d'avoir un seul et unique pipeline. Après si cela rend le code et la maintenance du pipeline trop compliqué il faut splitter. On peut très bien avoir un pipeline qui va gérer du java et du python, go etc. Faut trouver le bon équilibre suivant les usages. ++
@@xavki hello oui je suis parti sur du split du coup. Merci. Domaine par domaine c'est plus simple sur la construction et j'espère la maintenance, les tests et l'appropriation. Surtout quand peu de personnes maîtrisent les subtilités du code gitlab-ci.
Merci pour l'outil escali draw
Avec plaisir. Ah mais je suis ta chaîne aussi 😉
@@xavki c'est super. Tu fais également de très bon contenu.
J'adore cet outil.
Des fois, le client veut faire du Devops sans méthode Devops ... du coup on est pris en étau.🤔
On fini par faire des chaines CI-CD de chaine de CI-CD. 🤨
Merci pour le REX.
Ok intéressant.
Alors sur le concept je comprends. Par contre à mettre en place je vois pas trop comment faire sans tout casser 😅
C’est exactement mon cas 120 CI 😥donc comment target und ci dans sont dépo depuis mes projets gitlab 🤔 un petit liens gitlab stp
Hello. Il faut utiliser les trigger et trigger un projet unique dédié au pipeline. Perso je préfère Jenkins pour cet aspect. Regarde la playlist gitlab qui pourra peut-être te donner des idées.
Merci je viens de voir que (include )permet de faire référence à une pipeline comme tu dis localiser dans un projet.
Sur nos projets on utilise Include du gitlabci