Super intéressant, merci à toi.
Pour ma part on est soit sur git flow ou alors un mode un peu a lâarrache avec une seule branche master
+1 pour du contenu lĂ -dessus câest top
Super intéressant, merci à toi.
Pour ma part on est soit sur git flow ou alors un mode un peu a lâarrache avec une seule branche master
+1 pour du contenu lĂ -dessus câest top
Super intéressant comme sujet et merci.
Je suis du mĂȘme avis que toi concernant Gitflow, lâutilisation de deux branches perpĂ©tuelles nâa pas vraiment de sens.
Par contre jâai aussi du mal avec le gitlab flow basĂ© sur les environnements principalement pour deux raisons :
Personnellement, je préfÚre bosser avec GitLab flow basé sur les release branches.
Dâailleurs, comment gĂ©rez-vous les workflows basĂ©s sur des dĂ©ploiements de containers ?
Salut Super article.
Je connaissait gitflow et on lâa utilisĂ© un moment mais nous avons arrĂȘtĂ© de lâutiliser pour un systĂšme qui lui ressemble mais un peu modifiĂ© Ă ma sauce.
Du coup moi je fais un peu un mix (avec Master / Development / Nouvelle branche) :
Important :
Voila ;p
Merci encore et bonne journée à tous.
Dâailleurs, comment gĂ©rez-vous les workflows basĂ©s sur des dĂ©ploiements de containers ?
Personnellement je reste simple. Jâai travaillĂ© sur des projets avec des gestions dâarbres Git complexe, jâai toujours trouvĂ© que le gain ne valait pas la complexitĂ© apportĂ©e.
OĂč je suis, chaque commit sur une branche construit une image Docker du projet. Cette image peut ĂȘtre dĂ©ployĂ©e sur un environnement de dev si besoin pour faire des tests.
Une fois merge sur master, la CI crĂ©e automatiquement un tag et incrĂ©mente la version du projet. Cette release est ensuite dĂ©ployĂ©e sur les diffĂ©rents environnements (preprod, prodâŠ) par les dĂ©veloppeurs.
On est donc pas sur du dĂ©ploiement continu, câest au dev de faire lâaction de dĂ©ployer. Mais on commence Ă passer nos apps sur ArgoCD (on a notre propre outil interne de gĂ©nĂ©ration de manifests Kubernetes et de gestion de version des applications par environnement quâon a intĂ©grĂ© avec ArgoCD car personne aimait Kustomize), mais notre façon de gĂ©rer les dĂ©pĂŽts Git ne devrait pas changer.
Hors conteneurs (applis packagĂ©s dans des .deb par exemple) câest un peu pareil. La CI pousse un paquet dans un dĂ©pĂŽt âtestâ qui peut ĂȘtre installĂ© sur un ou des serveurs pour tests. Une fois merge sur master, un paquet est construit est poussĂ© dans un repo âstagingâ et dĂ©ployĂ© sur les environnements du style preprod. Pour dĂ©ployer en prod, on nâa quâĂ promote le paquet de staging dans le dĂ©pĂŽt de prod.
On fait presque la mĂȘme chose Ă la diffĂ©rence quâon ne merge pas directement les features branches dans la branche master, on passe prĂ©fĂ©rablement par une release branche.
Sinon au niveau des dĂ©ploiements en prod, câest pareil que vous, câest une Ă©tape Ă dĂ©clenchement manuelle, car gĂ©nĂ©ralement les dev doivent avoir le âgoâ du PO.
Pour Kustomize, on a regardé mais pas utilisé non plus. Helm semble suffir à nos besoins.
Jâai une prĂ©fĂ©rence pour gitlab flow (que jâutilise depuis 3 ans sans savoir que ça avait un nom). Ăa permet que tout soit contrĂŽlĂ© par des merges request trĂšs facilement. Depuis que je lâai mis en place, on nâa quasiment plus dâerreurs en prĂ©-production, la gestion des rollbacks est beaucoup plus simple (mais du coup, on nâa plus vraiment Ă en faire dans cette configuration) et tout le monde voit dâun seul coup dâĆil ou en est chaque environnement.
Câest un des gros avantage que je vois dans le GitLab flow.
Mais dâun autre cĂŽtĂ© le livrable est diffĂ©rent hors jâai pour habitude de mâassurĂ© que le livrable es identique dans les environnement, cela rĂ©duit les erreurs de dĂ©ploiement de production.
Câest pour moi le gros point noir qui fait que je ne suis pas passĂ© au GitLab flow.
Cette vidéo fait bien réagir, que ce soit ici, sur YouTube ou sur les slacks ou je suis.
Cela veux dire que ce genre de contenu vous plais.
Je vais rĂ©flĂ©chir Ă dâautres bonnes pratiques DevOps Ă mettre en place pour en faire des vidĂ©os.
Argh⊠je ne suis vraiment pas fan des vidĂ©os (et de youtube), mais le sujet mâintĂ©resse beaucoup et comme la vidĂ©o de @cchaudier sur les groupes/sous-groupes GitLab mâa Ă©tĂ© profitable, je vais faire lâeffort dâaller la voir.
En attendant, ayant bossĂ© seul pour mes dĂ©buts et ayant Ă©tĂ© pas mal effrayĂ© par les articles traitant dâartillerie vraisemblablement trop lourde pour mes besoins, jâai construit mon propre flow en me fixant des rĂšgles de base que je faisais Ă©voluer (si besoin). Au bout de 7 mois, je lâai prĂ©sentĂ© dans un meetup AFPy Lyon avec pas mal de retours positifs : mais les Pytholyonnistes sont bienveillant .
LâarrivĂ© de mon 1er collĂšgue (mai 2020) mâa motivĂ© pour le documenter clairement. Je viens de publier publiquement mon embryon de manuel de travail, mes conventions git
sont la partie principale de ce projet.
Au final je dirais que le meilleur flow est celui qui Ă Ă©tĂ© construit par lâĂ©quipe qui lâutilise, pas celui que lâon Ă vu ailleurs et que lâon essaye de (faire) suivre.
Qui à dit «DevOps» là bas dans le fond ?
Pour ma part, jâutilise le mĂȘme workflow a un dĂ©tail prĂšs: les merges sont interdit, tout le code qui va partir sur les branches principale doit ĂȘtre dâabord rebasĂ© sur la branche principale de dev par le dĂ©veloppeur. Ca permet:
Câest le dĂ©veloppeur qui sâoccupe du rebase (mĂȘme complexitĂ© quâun merge), et câest le mieux placĂ© pour faire ça.
Ca permet dâavoir un historique de commit linĂ©aire qui permet dâutiliser âgit bisectâ pour rĂ©pondre a la question: depuis quel commit le bug est-il apparu. (note: je lâutilise plus sur les projets C que sur les projets PHP).
Jâavais Ă©crit un article pour prĂ©senter la base de mon workflow que jâadapte en fonction du projet, de si on fait de la CI uniquement ou si on veut aussi du CD, et des sensibilitĂ©s de lâĂ©quipe (me but Ă©tant que tout le monde soit en phase avec la maniĂšre de travailler) : https://gastaud.io/article/git-workflow/
Il nây a pas de rĂ©volutions dedans. Plus un mĂ©lange des diffĂ©rentes approches
Si vous avez des questions, nâhĂ©sitez pas !
Il faudrait que je montre le flux complet que jâutilise. Mais ça risque de faire une vidĂ©o de plus de 30 min. Cela pourrait-ĂȘtre lâobjet dâune petite formation.
Je présente une version simplifié ici : https://www.youtube.com/watch?v=RqPxcBVGDoU
Personnelement je nâaime pas la solution qui permet Ă un humain de pousser sur la branche principale. Car du coup il peu casser quelque chose. Ă partir du moment ou tu peu mettre des commit sur master qui ne sont pas passĂ©s par une CI ça peu nous arriver.
Par contre on fait toujours des rebases avant de faire une revue de code. Pour ĂȘtre sur que le code est Ă niveau. De toute façon GitLab nous le dit quand câest pas le cas.
Les seules merge que lâon fait sont ceux de gitlab apres la revue.
Lâhistorique nâest pas trop mauvais en utilisant cette mĂ©thode : https://gitlab.com/lydra/shellfactory/-/network/master
Han⊠il me tarde de pouvoir essayer git bisect
, mais je dois avoir de trop bonnes pratiques pour ne pas encore en avoir besoin
Jâai du utiliser ca une seule fois avec du PHP, en revanche avec du code C sur des projets complexe, je mâen sert dĂšs que le bug est dur Ă trouver. Câest vraiment top comme fonctionnalitĂ©: on indique un commit qui fonctionne, un commit qui ne fonctionne pas, et âgit bissectâ va dĂ©marrer une recherche dichotomique. A chaque Ă©tape il demande au dĂ©veloppeur si le commit est bugguĂ© ou non. A la fin, il dĂ©duit quel est le premier commit Ă prĂ©senter le bug. Ca permet de trouver le commit qui amĂšne le bug, et donc de comprendre lâĂ©tat dâesprit du dĂ©veloppeur et de savoir ce quâil voulait faire lorsquâil a codĂ© le bug. Cela permet donc de le corriger efficacement ou de savoir Ă qui sâadresser.
En revanche, cela demande deux conditions qui ne sont pas simple a réunir:
Câest utile en C pour les bug de type dĂ©bordement de mĂ©moire, ou un fonctionnalitĂ© ajoutĂ©e met la pagaille dans la mĂ©moire, et dĂ©clenche un plantage ailleurs dans le code.
Jâessaie de me documenter rĂ©guliĂšrement sur ce sujet afin de rester Ă jour et dĂ©couvrir de nouvelles pratiques, câest ainsi que je suis tombĂ© par hasard sur cet article et cela ressemble fortement Ă lâapproche que jâai adoptĂ©.
Je continue ma dĂ©couvert de IFTTD et je tombe sur lâĂ©pisode avec Dimitri Baeli qui aborde le continuous merge :
Sa proposition de continuous merge me parle vraiment.
Les merges mâont longtemps fait peur, jâai «rĂ©glé» le soucis avec un outil de merge graphique : mais plus le temps passe, moins ça me convient. je me suis dĂ©jĂ plusieurs fois surpris a annuler un merge «simple» pour rectifier la branche Ă la place et les merges «complexes» me donnent toujours lâimpression de «refaire» voir carrĂ©ment de «casser» le boulot pour le «faire rentrer».
Bref, jâai parcouru rapidement la doc de git octopus
mais elle me semble moins accessible que ces quelques minutes de présentation dans le podcast.
Si quelquâun Ă dâautres ressources ou de lâexpĂ©rience Ă me proposer sur ce sujet je suis preneur.
Je dois pas ĂȘtre frais ce matin, jâai regardĂ© la doc de git-octopus mais je nâai pas compris en quoi cela diffĂšre des workflows ordinaires.
Tu as souvent des soucis de merge ? Quel stack technique ?
Jâavais Ă©coutĂ© cet Ă©pisode de IFTTD mais je nâavais pas Ă©tĂ© convaincu par ce workflow.
Au final câest du githubflow mais ou on a remplacĂ© la feature-branch par une dev-branch.
Je suis pas super embalĂ© car si un dev bloque sur une fonctionnalitĂ© la branche ne peu pas ĂȘtre reprise par un autre dev, ce qui peu lâĂȘtre dans le githubflow.
Je prefĂšre largement le githubflow gĂ©rĂ© avec GitLab comme je lâai montrĂ© dans cette vidĂ©o.
Je laisse toujours GitLab mergĂ©, ce qui me permet dâinterdire Ă tout le monde de pousser sur master et seul les personnes avec le role maintainer peuvent merger.
Je nâai pas compris non plus lâinteret de git-octopus.
Nous avons peu de conflicts de fussion mais câest aussi par ce que je demande Ă toute mon Ă©quipe de faire un rebase depuis master avant de proposer sa fonctionalitĂ© Ă la revue.
Oups, en fait le message que jâavais mis ici est bien mieux placĂ© lĂ :
Un message a été fusionné à un sujet existant : TUTO | GitLab | Comment ranger ses dépÎts GitLab?
Pour complément sur ce sujet, Martin Fowler a écrit un article trÚs complet : https://martinfowler.com/articles/branching-patterns.html