Bonjour à tous,
je continue mon apprentissage de GIT et sollicite vos conseils sur l'organisation d'un dépôt
je développe/maintiens une appli pbp assez importante pour un client, celui-ci me met à disposition 2 environnements LAMP, l'un de TEST et l'autre de PROD
je pensais donc avoir 1 dépôt GIT avec 2 branches correspondant aux 2 environnements TEST et PROD
tous les 6 mois environ, j'ai une commande pour faire évoluer l'application, évolution décomposée en 10 à 20 modifications/ajouts de fonctionnalité,
mais parfois, certaines modifications/ajouts ne sont pas mises en prod (ou plus tard)
alors je suppose que pour rendre chaque modif/ajout indépendant des autres, je dois faire autant de branches ?
et si oui, est-ce que vous me conseillez d'abandonner la branche TEST (ne conserver que la branche PROD et autant de branches que de mini-évolution) ???
merci d'avance pour vos avis
# Git Flow
Posté par Jérôme FIX (site web personnel) . Évalué à 4.
Bonjour,
Tu peux jeter un œil à Git Flow
Tu peux sans doute utiliser ce workflow pour faire tes releases, conserver chaque fonctionnalité dans une branche jusqu'à son intégration, …
Jérôme.
[^] # Re: Git Flow
Posté par _kaos_ . Évalué à 3.
Salut,
Oui, git flow ça facilite bien les choses.
Dernièrement, j'avais un environnement un peu comme ça :
Donc pour chaque « feature », on partait de la dernière dev, et pushait dessus pour tester (en gros tout dev pouvait pusher sur l'infra - en prévenant bien sûr). Une fois le cycle de développement en dev fait, là ça passait en préprod (avec un dev d'astreinte). Si ça pétait pas, alors ticket pour déploiement en prod avec instructions claires pour l'équipe SRE.
Matricule 23415
[^] # Re: Git Flow
Posté par pralines . Évalué à 1.
merci, très intéressant
à propos de git flow : je ne sais pas si ces extensions sont installées sur le dépôt de mon client, mais de par la nature distribuée de git ça ne doit pas être bloquant non ?
je dois pouvoir l'utiliser sur mon poste pour gérer toutes les branches (pour l'instant, je suis le seul dev/mainteneur de l'appli) ?
Envoyé depuis mon Archlinux
[^] # Re: Git Flow
Posté par _kaos_ . Évalué à 1.
Salut,
Non, c'est un wrapper qui t'aide dans l'usage de git, donc ce n'est pas bloquant du tout.
A un moment, pour une raison de migration vers un repo interne, je ne pouvais plus l'utiliser (car configuration pas finie), ça m'a juste ralenti un peu en revenant à du git « de base ».
Matricule 23415
[^] # Re: Git Flow
Posté par 16aR . Évalué à 2.
Personnellement, j’étais à fond sur cette méthode au début, puis j’ai été face à plusieurs autres méthodes. Dernièrement, après quelques questionnements, j’ai vérifié ce que faisait le créateur de cette méthode: il ne l’utilise sur aucun de ses repo github récents ! Et il faut les chercher les peu de repo où il a utilisé sa propre méthode.
La seule défense que je pourrais avoir, c’est qu’il ne l’utilise que sur des repo privées professionnel d’envergure. Mais même là, j’ai un doute.
Le plus gros problème que je vois, c’est l’utilité de la branche master. Elle ne sert qu’à lister les différentes release. Sauf que je trouve que ça ne sert à rien et c’est même pas cohérent quand on a 2 versions majeures d’une même app.
Imaginons l’exemple d’une app en 2 versions: v2 et v3. v2 était en Node.js, et la v3 a été réécrite en Go.
Quelle est l’idée d’avoir sur master un tag v2.1.1 suivi d’un tag v3.0.0 puis ensuite un v2.2.0 ?
Pas du tout la même stack technique, on passe d’une branche a une stack node, vers du Go puis du node à nouveau ?
Pour cet exemple, je vois plus chaque version majeure sur sa branche de release. Excepté, la branche en cours de développement est sur master.
Seuls les tags garantissent une publication correcte. Le reste, c’est de l’état intermédiaire en plus ou moins bon état.
[^] # Re: Git Flow
Posté par 16aR . Évalué à 2.
La règle, c’est d’utiliser 1 branche de release par version majeure. Ou, d’1 branche release par version déployé, si c’est un logiciel déployé chez plusieurs client avec à chaque fois des devs spécifiques non mergeable sur la master/release dédiée.
# Master first
Posté par MrBidon . Évalué à 2.
Le gitflow c'est très compliqué si tu es tout seul ça ne sert à rien, je préfère l'approche "Master first" où on ne créer des branches de version que si c'est nécessaire.
En gros, tu développes dans la master tout le temps. Quand vient le moment de faire une release : tu créer un tag sur ta master et tu mets ta release en test si c'est ok tu la passes en prod.
Puis tu continue à faire tes dev sur la master, pour la vie de ton tag c'est à toi de voir, soit tu créer la release suivante directement sur la master, si tu juges qu'elle est assez mûre pour aller en prod, sinon tu crée une branche à partir du tag et tu cherry-pick le commit de la master, souvent c'est pour corriger des petites choses urgente pendant que la master se fige.
[^] # Re: Master first
Posté par _kaos_ . Évalué à 1. Dernière modification le 15 février 2020 à 14:12.
Salut,
Heu, je veux bien un exemple, parce que moi qui ne suis pas un cador de git, j'ai trouvé que ça me simplifiait globalement la vie, et qu'en cas de problème je pouvais quand même retourner à du git « de base ».
Certes, je n'ai pas fait le worflow, mais sur des usages simples, je n'ai pas eu l'impression que ça représente des masses de boulot.
Hmm, mauvaise pratique du watterfall ?
Matricule 23415
[^] # Re: Master first
Posté par MrBidon . Évalué à 2. Dernière modification le 15 février 2020 à 19:55.
Ca s'appelle upstream first en fait, je pense que j'avais lu ça ici :
https://docs.gitlab.com/ee/topics/gitlab_flow.html#release-branches-with-gitlab-flow
Bonne lecture
[^] # Re: Master first
Posté par pralines . Évalué à 1.
effectivement, je suis seul (pour l'instant), donc peut-être pas intérêt à compliquer inutilement les choses
j'aime bien ces branches release qui permettent de rapidement sélectionner une version antérieure
mais dans ce cas, où appliquer un hotfix en urgence ?
pas sur le master, sinon on risque de publier des choses qui ne sont pas testées/souhaitées
si hotfix sur branche dernière release stable, comment envoyer le hotfix sur le master pour ne pas faire une régression à la prochaine release ?
avec les tags ?
je ne connais pas, n'est ce pas un peu dangereux (ou pénible) ???
Envoyé depuis mon Archlinux
[^] # Re: Master first
Posté par MrBidon . Évalué à 1.
Il faut corriger le soucis sur la master dans un commit bien identifié, puis "checkouter" le tag et créer une branche.
Une fois sur la branche tu fais un cherry-pick du commit contenant le hotfix.
[^] # Re: Master first
Posté par pralines . Évalué à 1.
il faut donc aussi avoir une bonne gestion des TAGs
est-ce qu'il est recommandé d'avoir des TAGs synchronisés avec le N° de version de l'application ?
peut-on inclure des lettres dans les tags (pour distinguer les releases avec hotfix des releases normales) ou bien cela va gêner les opérations logiques dans les recherches/filtres sur les TAGS (si cela existe) ?
Envoyé depuis mon Archlinux
[^] # Re: Master first
Posté par MrBidon . Évalué à 1. Dernière modification le 17 février 2020 à 15:22.
Tu fais comme tu veux en fait c'est ça qui est bien avec GIT :) et ce que tu dis c'est ce que je fais, je me prend pas la tête (on fait une release toute les semaines :-))
J'ai un numéro de build et je l'incrémente à chaque nouvelle version. Pour les hot fix, je mets une lettre à coté. La première release est appelée 851a, les hot fix suivant sont dans les versions 851b, 851c… le tout tourne sur la branche 851.
Il faut mieux décoreller le numéro de build (utilisation technique) du numéro de version (utilisation commerciale).
[^] # Re: Master first
Posté par 16aR . Évalué à 1.
Perso je préfixe mes version publié par vX.Y.Z en mode versionnage semantique.
Et sinon, tout ce que je pushe est buildé par la CI, et ces version intermédiaires sont versionnées avec le hash du commit git.
[^] # Re: Master first
Posté par MrBidon . Évalué à 1.
Moi je ne build que sur tag parce chaque release fait 1GB ;-)
[^] # Re: Master first
Posté par _kaos_ . Évalué à 1.
Salut,
Mouaif, avec un disque d'1To t'as de la marge…
Matricule 23415
[^] # Re: Master first
Posté par MrBidon . Évalué à 1.
J'aime faire autre chose que l'ops, du coup, le gitlab il est hébergé dans le cloud, le GB y est plus cher :)
[^] # Re: Master first
Posté par 16aR . Évalué à 2.
carrément, c’est vraiment ce que je reproche.
Sur le papier, ça a l’air assez simple, mais une fois à gérer au jour le jour avec des merges à droite à gauche, ça devient vite le merdier.
[^] # Re: Master first
Posté par MrBidon . Évalué à 1.
On fait ça depuis 6 mois dans l'équipe (5 personnes) et ça se passe bien. Rien n'empêche de faire des branches avec rebase régulier si on fait des gros changements :)
[^] # Re: Master first
Posté par 16aR . Évalué à 2.
Je n’ai pas été assez explicite, je disais que je reprochais à gitflow la même chose que toi.
Et je suis aussi a vraiment plutôt faire du master first, avec une branche de feature/fix plutôt temporaire pour éviter les rebase/merge violent lorsqu’on se resynchro.
[^] # Re: Master first
Posté par MrBidon . Évalué à 1.
Sisi on s'était bien compris, après vérification c'est "upstream first" qu'ils appellent ça (méthode utilisé chez Red Hat et Google), le titre de ce thread n'est que mensonge :)
# git flow + releases
Posté par François GUÉRIN (Mastodon) . Évalué à 1.
Salut?
Je suis également seul dev dans ma structure, j'utilise
git flow. Il me permet de jongler avec les différentes features / bugfix…Pour le déploiement, j'utilise des tags sur la branche master pour la PROD, et la branche "develop" brute pour la pré-prod (STAGING). La préprop peut casser, mes utilisateurs sont au courant :)
Le processus de déploiement est "à la demande": j'ai un rôle ansible qui fait le taff quand j'en ai besoin, avec un script maison
deploy.shqui n'est qu'un lanceur pour le rôle ansible.Du coup, j'utilise pour mettre en prod :
git flow release start <version>git commit(dans la branche release/)git flow release finish./deploy.sh<< Vers la pré-prod./deploy.sh -m PROD<< Vers la prodL'avantage de cette approche, c'est que je peux à tous moments pousser vers la staging (branche develop), mais que je ne peux pas pousser "par accident" dans la PROD.
Le process est à la fois contraignant mais pas trop, et avec le rôle ansible, je n'oublie rien.
Je déploie environ 20 projets différents avec cette méthode, et j'en suis très satisfait.
Ah, et j'ai un script python pour faire les montées de version:
https://pypi.org/project/bump-release/
Ce script ne fait que mettre à jour les numéros de version dans différents points du projet (main, docs, ansible vars pour récupérer le bon tag quand je déploie), il ne fait rien avec GIT.
Pour info, je fais quasi exclusivement du Django / python…
[^] # Re: git flow + releases
Posté par pralines . Évalué à 1.
salut
et ton script deploy.sh envoie en pré-prod (par défaut) uniquement les fichiers modifiés ou bien il envoie toute la branche release ?
(par ftp ?)
Envoyé depuis mon Archlinux
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.