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 
1 « J'aime »
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 :
- Il y a des risques que les changements ne soient pas portés à l’ensemble des branches (environnements).
- On se retrouve à déployer des artefacts différents d’une environnement à l’autre pour une même version du code (même ensemble de fonctionnalités).
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 ?
1 « J'aime »
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) :
- Je crée une branche depuis Development pour ma nouvelle feature
- Dès que c’est bon je merge cette nouvelle branche dans DEV et j’ajoute un tag.
Ce tag lance gitlab-CI pour créer une image docker qui utilise la version du tag et la pousse sur l’environnement de DEV automatiquement. - Si tout est ok sur DEV, je merge DEV sur master et l’image précédemment créée pour DEV et ré-utilisée sur l’environnement de PROD (le manifest k8s du git de production est changé pour la nouvelle version de l’image), via une action manuelle pour éviter le déploiement automatique en cas d’erreur.
Important :
- La nouvelle branche merge sur DEV permet de lire facilement le code ajouté plus tard ou de faire une review.
- Le tag sur dev permet de lié fortement une version d’une image docker avec le code source (pour un retour sur cette version si besoin).
- L’image de dev doit être la même que celle utilisée sur master afin d’être certain que cette image fonctionne parfaitement. De plus la branche Master (que je vais surement maintenant nommée Main) doit toujours etre le reflet de ma production afin de faire un quick fix si besoin.
- Avant entre DEV et PROD on utilisait un environnement QA pour qu’une ou deux personnes test la chose, mais ça c’est malheureusement perdu… domage je trouvais que c’était une bonne chose !
Voila ;p
Merci encore et bonne journée à tous.
1 « J'aime »
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.
1 « J'aime »
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.
1 « J'aime »
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.
1 « J'aime »
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.
1 « J'aime »
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 ? 
4 « J'aime »
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).
1 « J'aime »
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:
- Une branche de commits linéaire (pas de merge, ou du moins pas sur la section a tester)
- Chaque commit doit être fonctionnel, sinon on ne peut pas le tester (enfin, on peut tolérer quelque commits non fonctionnels, mais il faut s’adapter)
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é.
1 « J'aime »
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à :
1 « J'aime »
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
1 « J'aime »