En tout cas, je ne te souhaite pas de mal, mais j'espère que tu ne sere pas un jour la victime collatérale de quelqu'un qui "ne s’embarrasse pas des vies civiles"
(putain, si on m'avait que je défendrais albert un jour…)
Nous vivons un grand moment de L'Histoire sur DLFP.
Les ennemis de mes ennemis sont mes amis…ennemis…je sais plus. … Demerden sie sich
En tout cas, si tu pouvais nous pondre une diatribe du même acabit sur notre nain qui passe par la fenêtre lorsqu'on ne l'a pas invité, je suis preneur.
Ouais Obama en avait fait un de ses thèmes de campagne et il s'est retiré d'Irak.
Et on voit ce qu'il en est ailleurs. Les US ont des partenaires dans l'OTAN , un modèle judéo-chrétien (au pire) et laic (au mieux) à défendre.
Les neos cons sont les plus interventionnistes et sont toujours aux aguets et ne laisseront pas Trump s'isoler. soyons réalistes.
Et on ne parlera pas de leurs motivations à intervenir (business is business, rather ethical)
Je préfère un langage de vérité qu'un faux-cul qui fera le contraire de ce qu'il dit. désolé.
Mais je ne suis pas américain non plus.
Et ca me fait marrer la cohérence de qq1 qui soutient le désengagement notamment dans les pays islamisés et qui soutient les partis islamophobes.
La fibre "conservatrice" d'abord ? dissonance cognitive ?
Latex a sûrement énormément de vertus mais à vous lier ça parait quand même effrayant.
Quitte à attirer des contributeurs une solution type Gitbook couplée avec le plugin qui va bien ça ne serait pas plus "accessible" au commun des mortels ?
Il y atoujours possiblité de monter des toolchains vers du PDF.
sur la video 14 iphone et un macbook Air:
Sur le store en prenant le plus cher des iphone (909 euros) et le plus cher des macbook air (13 pouces = environ 1900) on arrive grand max à 15k.
Après il a peut-être détérioré avant la prise de vue mais faudrait le prouver.
Finalement c'est tellement cheap qu'on peut vraiment e demander si appeule c'est de la merde cinoise :)
"update" doit faire un fast-forward, sinon cela entraîne un merge qui pourris l'historique.
L'option --rebase t'évite un merge. Par contre, en cas de conflit, tu es interrompu au milieu de ton rebase.
Du coup, il vaudrait mieux squasher avant:
Ton publish doit comporter un git rebase, avant le push,
Avec svn si tu es empêché de commiter tu updates. Tu n'updates pas avant. Je suppose que tu veux rebaser pour les fichiers disjoints et échouer s'il y a un conflit.
IJe n'ai pas vu d'option de rebase qui le permettrait.
En fait, je pensais plus que tu proposerais une série d'alias précis qui correspond à différentes étapes de ton propre flow.
Je pourrais présenter les commandes enchainées. Mais l'intérêt de l'outiller me parait superflu étant donné qu'il est finalement assez simple.
Mais tu attaques le mauvais projet : avec GitLab, tout le monde peut faire exactement le même business que GitLab, car gitLab n'interdit pas de faire comme eux (c'est du MIT, et non du GPL)
Toutes mes confuses alors ! J'étais persuadé qu'il s'agissait d'AGPL
Je retire mes propos.
Il publie un outil** complet** qui te permet de répliquer ces fonctionnalités où tu veux, comme tu veux, sans dépendre de leurs serveurs.
Je ne comprends pas ce qui te fait dire cela.
Exemple:
Notons que les deux premiers points (plusieurs vues et une vue pour un groupe) sont destinés à l’édition entreprise de GitLab (et donc aussi à la version en ligne gitlab.com), pas à sa version communautaire.
Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …
Encore une fois, je comprends que chacun ait le droit de vivre de son travail. Mais expliquez ce qu'il y a de plus respectable à dire:
Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public
et
Si tu veux utiliser tous mes services chez toi payes. Pour les sources tu peux m'aider mais je conserve un avantage commercial sur toi. Toi tu reverses, moi non. Quelle différence au final avec une licence non libre sur du contenu telle que la CC-BY-NC. C'est de la pure hypocrisie.
Github étant contributeur open-source par ailleurs je me permets de répondre à l'auteur du commentaire qui semble avoir un parti pris.:
Le jour où Framasoft grandit, fédère des contributeurs et diverge du core au point que la version commerciale de Gitlab ne pourrait suivre, on en reparlerait ok ?
Vi enfin entre Github et un projet qui fait de l'open-source washing (Contribuez, on est des gentiiiiils et nous on garde le beurre), je vois pas la différence. Autant prendre l'original !! Et les alternatives purement open-source ne manquent pas. Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.
Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence. Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?
Sinon, pour les spécialistes, si on contribue en open-source à réimplémenter leur feature proprio, on risque pas de se prendre un procès ?
Accessoirement, Mattermost, leur partenaire a exactement le même modèle.
Pas que je sois contre, chacun a le droit de vivre. Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !
Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.
Les seules adaptations concernent:
1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
2. Les features branch:
Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).
Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:
Car l'un à la granularité du dépot, l'autre des fichiers.
De la branche plus exactement.
C'est la raison pour laquelle j'expliquais que dans une migration git avec plusieurs composants (/comp1/trunk, /comp1/v.1.x, /comp2/trunk, …), une des solutions est de créer des branches équivalentes.
Ainsi, tu n'es pas pollué par les commits dans les autres branches, y compris celles des autres composants.
Et par ailleurs, la granularité de SVN pour un commit est par contre le dépôt (une révision par depôt). Mais grâce au fameux buble-up, il est capable de commiter des fichiers qui n'entrent pas en conflit, et tout ça de manière transactionnelle (contrairement à ce bon vieux CVS).
Je voudrais troller, je dirais que t'as l'air assez dogmatique dans ton agilité :)
Ce n'est vraiment pas ton genre :)
Un paramètre crucial dans le feature branch, c'est la durée de vie de la branche. Une branch qui vit 2-4 jours (sur un sprint de disons 2 semaines), c'est pas le bout du monde.
Ton intégration continue s'en sortira, et tes merges aussi.
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, … Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Juste pour être clair - tu comittes/push direct sur master? Genre plusieurs fois par jour?
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Et le mec qui fait un refactoring sans demander si quelqu'un bosse sur la partie refactoree, il mérite un peu des claques, non?
Y’en a encore qui osent refactorer dans ton équipe ?
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence,
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer …). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.
Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, … à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Le premier est l'intégration continue. Tout est intégré au fil de l'eau
Le second est le continuous delivery. On fait en sorte que tout ce qui est intégré soit potentiellement déployable (build au vert et tests automatisés à gogo pour s'assurer de la qualité de la livraison)
Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas).
Wikipedia explique très bien la différence
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile
[^] # Re: Merci
Posté par El Titi . En réponse à la dépêche surveillance:// Entretien avec son auteur Tristan Nitot et 10 livres à gagner. Évalué à 2.
Est-ce que la police peut jeter l'opprobre sur toi parce que tu as snapchatté imprudemnent ? Oui
[^] # Re: Motivations ?
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à -1.
MOUARF
Et on ne parlera pas de l'annexion de la Crimée.
[^] # Re: Motivations ?
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 3.
Donc si ion résume ta position, tu critiques les américains d'être interventionniste et tu encenses la Russie parce qu'ils sont interventionnistes…
Mais c'est pas pareil les premiers ce sont des mauvais chasseurs
[^] # Re: Motivations ?
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 2.
En tout cas, je ne te souhaite pas de mal, mais j'espère que tu ne sere pas un jour la victime collatérale de quelqu'un qui "ne s’embarrasse pas des vies civiles"
[^] # Re: Wikileaks n'est plus, évitez d'aller lire c'est du voyeurisme peu honnête
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 1.
Nous vivons un grand moment de L'Histoire sur DLFP.
Les ennemis de mes ennemis sont mes amis…ennemis…je sais plus. … Demerden sie sich
En tout cas, si tu pouvais nous pondre une diatribe du même acabit sur notre nain qui passe par la fenêtre lorsqu'on ne l'a pas invité, je suis preneur.
[^] # Re: Motivations ?
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 0.
Ah oui … d'où la théorie du complot, Sorel et consorts.
Bel esprit critique.
[^] # Re: Wikileaks n'est plus, évitez d'aller lire c'est du voyeurisme peu honnête
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 3.
Ouais Obama en avait fait un de ses thèmes de campagne et il s'est retiré d'Irak.
Et on voit ce qu'il en est ailleurs. Les US ont des partenaires dans l'OTAN , un modèle judéo-chrétien (au pire) et laic (au mieux) à défendre.
Les neos cons sont les plus interventionnistes et sont toujours aux aguets et ne laisseront pas Trump s'isoler. soyons réalistes.
Et on ne parlera pas de leurs motivations à intervenir (business is business, rather ethical)
Je préfère un langage de vérité qu'un faux-cul qui fera le contraire de ce qu'il dit. désolé.
Mais je ne suis pas américain non plus.
Et ca me fait marrer la cohérence de qq1 qui soutient le désengagement notamment dans les pays islamisés et qui soutient les partis islamophobes.
La fibre "conservatrice" d'abord ? dissonance cognitive ?
[^] # Re: wikileak n'a plus aucune credibilite
Posté par El Titi . En réponse au journal Wikileaks a retrouvé une partie des mails de Hillary Clinton. Évalué à 6.
Dit-il sur un ton Hilare !
[^] # Re: Oui mais....
Posté par El Titi . En réponse à la dépêche Six nouveaux services chez Framasoft (30 au total). Évalué à 4. Dernière modification le 08 octobre 2016 à 13:02.
Pitié, ne suppl*a*nte pas ma vue !
[^] # Re: Système de compilation LaTeX
Posté par El Titi . En réponse à la dépêche Le Frido, un livre de mathématique libre pour l’agrégation. Évalué à 3.
Latex a sûrement énormément de vertus mais à vous lier ça parait quand même effrayant.
Quitte à attirer des contributeurs une solution type Gitbook couplée avec le plugin qui va bien ça ne serait pas plus "accessible" au commun des mortels ?
Il y atoujours possiblité de monter des toolchains vers du PDF.
[^] # Re: Sai daigueulasse
Posté par El Titi . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 2.
Tous des fadas, ces divodorumains:
https://twitter.com/Quentin_IOS/status/781854845103902720
[^] # Re: $
Posté par El Titi . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 3.
sur la video 14 iphone et un macbook Air:
Sur le store en prenant le plus cher des iphone (909 euros) et le plus cher des macbook air (13 pouces = environ 1900) on arrive grand max à 15k.
Après il a peut-être détérioré avant la prise de vue mais faudrait le prouver.
Finalement c'est tellement cheap qu'on peut vraiment e demander si appeule c'est de la merde cinoise :)
[^] # Re: Sai daigueulasse
Posté par El Titi . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 10.
[^] # Re: $
Posté par El Titi . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 6.
J'parie qu'il a renversé de la bière sur son macbook à 2500 boules et qu'Apple refuse de faire marcher la garantie.
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
L'option --rebase t'évite un merge. Par contre, en cas de conflit, tu es interrompu au milieu de ton rebase.
Du coup, il vaudrait mieux squasher avant:
Avec svn si tu es empêché de commiter tu updates. Tu n'updates pas avant. Je suppose que tu veux rebaser pour les fichiers disjoints et échouer s'il y a un conflit.
IJe n'ai pas vu d'option de rebase qui le permettrait.
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 4.
Tout le monde a le droit de se tromper. Merci de ne pas y prêter des intentions et les vaches seront biens gardées
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 6. Dernière modification le 21 septembre 2016 à 22:28.
Toutes mes confuses alors ! J'étais persuadé qu'il s'agissait d'AGPL
Je retire mes propos.
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à -3.
Exemple:
Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …
Encore une fois, je comprends que chacun ait le droit de vivre de son travail. Mais expliquez ce qu'il y a de plus respectable à dire:
Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public
et
Si tu veux utiliser tous mes services chez toi payes. Pour les sources tu peux m'aider mais je conserve un avantage commercial sur toi. Toi tu reverses, moi non. Quelle différence au final avec une licence non libre sur du contenu telle que la CC-BY-NC. C'est de la pure hypocrisie.
Github étant contributeur open-source par ailleurs je me permets de répondre à l'auteur du commentaire qui semble avoir un parti pris.:
Le jour où Framasoft grandit, fédère des contributeurs et diverge du core au point que la version commerciale de Gitlab ne pourrait suivre, on en reparlerait ok ?
Bref, je maintiens: open-source washing
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à -1.
Vi enfin entre Github et un projet qui fait de l'open-source washing (Contribuez, on est des gentiiiiils et nous on garde le beurre), je vois pas la différence. Autant prendre l'original !! Et les alternatives purement open-source ne manquent pas. Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.
Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence. Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?
Sinon, pour les spécialistes, si on contribue en open-source à réimplémenter leur feature proprio, on risque pas de se prendre un procès ?
Accessoirement, Mattermost, leur partenaire a exactement le même modèle.
Pas que je sois contre, chacun a le droit de vivre. Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !
[^] # Re: Quelle activité!
Posté par El Titi . En réponse au journal LinuxFr.org : première quinzaine de septembre 2016. Évalué à 2.
Nouveaux ou simplement actifs ?
Je suis vraiment une pôv moule accrochée à son bouchot :-(
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4. Dernière modification le 20 septembre 2016 à 21:35.
Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.
Notre workflow agile est très semblable à ce qui est proposé ici :
http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
(Le 2ème post apporte des précisions utiles)
Les seules adaptations concernent:
1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
2. Les features branch:
Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).
Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:
Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:
et une pour le resolve après un update:
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
De la branche plus exactement.
C'est la raison pour laquelle j'expliquais que dans une migration git avec plusieurs composants (/comp1/trunk, /comp1/v.1.x, /comp2/trunk, …), une des solutions est de créer des branches équivalentes.
Ainsi, tu n'es pas pollué par les commits dans les autres branches, y compris celles des autres composants.
Et par ailleurs, la granularité de SVN pour un commit est par contre le dépôt (une révision par depôt). Mais grâce au fameux buble-up, il est capable de commiter des fichiers qui n'entrent pas en conflit, et tout ça de manière transactionnelle (contrairement à ce bon vieux CVS).
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Ce n'est vraiment pas ton genre :)
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, … Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Y’en a encore qui osent refactorer dans ton équipe ?
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer …). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3. Dernière modification le 17 septembre 2016 à 20:41.
Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, … à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Et voici quelques ressources.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile