Posté par El Titi .
En réponse au journal Crawler web & Google Sets.
Évalué à 8.
Dernière modification le 11 décembre 2014 à 15:27.
Un crawler c'est un un genre de « Johnny Weissmuller ». Pour ceux qui ne l'ont pas connu, il permettait, à partir d'un ou deux mouvements de bras, de générer le reste du flim.
Tu ouvres un débat intéressant.
Pour le fait de se suffire à lui-même tu te focalises encore une fois sur la gestion de version.
Un outils de gestion de version montre pourtant ses limites rapidement pour l'analyse d'impact et oblige à des stratégies de contournements.
Comment reporter une demande de changement proprement qui recouvre plusieurs commits ?
Si elle est disséminée dans plusieurs commit d'une même branche. En se basant sur l'identifiant du ticket pour cherry picker les bon commits. En isolant une fonctionnalité dans une branche au détriment de la CI, autrement …
Je ne vais pas parler entrer dans un débat sur les mérites techniques d'autres outils proprio (il est clos aujourd'hui) mais certains d'entre eux résolvent élégamment en embarquant la notion de changement comme des entité à part entière dans l'outil et permettent une gestion à un plus haut niveau.
Par exemple Perforce ou Clearcase UCM avec ses activités. L'intégration d'une activité (deliver) merge automatiquement tous les changements associés. Des contrôles sont fait pour ne pas intégrer une fonctionnalité terminée si un commit associé à une autre non complétée
Un bon outil de gestion de conf par opposition à un outil de gestion de version offre donc une intégration plus cohérente avec un outil de suivi des changements.
Avec des outils open-sources qui ne sont pas prévus pour ça on se contente de referencer le ticket dans le commit etles comits associés dans le ticket.
Ca reste rudimentaire, peu fiable (on oublie son id de ticket on pushe et paf), pas très abouti pour la tracabilité et les reports sur d'autres branches.
Déjà, git est un DVCS. Donc comment tu fais pour consulter ton gestionnaire de ticket si t'es pas forcement connecté?
Comment dire !
Déjà est-ce pertinent de considérer le suivi des demandes de changements de manière distribuée.
Pour résoudre un ticket ou changer des tickets qui nous sont affectés ok. Pour prendre un ticket ouvert et se retrouver à faire le boulot en doublon parce qu'un autre a cloné la base de ticket en même temps et s'affecte le même ticket en loacal c'est moins pertinent.
Des solutions, il en existe pour le premier cas.
Avec Mylyn d'Eclipse, tu récupères tes tickets en local, tu bascules entre deux et tu commit avec le bon commentaire de tickets. (Sans parler de la gestion du contexte)
D'autres outils proposent une solution de SCCM (bug tracking + versionning) complètement distribuée et même en open-source
Fossil, Veracity (http://veracity-scm.com/)
Bref, si on met de coté les mérites techniques de Git pour automatiser certaines tâches et sa souplesse, face à ses challenger et la hormis hype portée par Linus, Git est loin d'être la meilleure option.
Ca y'est le débat Git vs (Hg|Bzr|???) est réouvert. Nostalgie !
Mais les moutons de Panurge que nous sommes doivent suivre. La guerre est terminée. Git sort vainqueur … pour le meilleur et pour le pire.
Et pour reprendre un peu ce que dit Gama plus bas.
Si vous maintenez plusieurs branches d'intégration, y'a peut-être des trucs à faire pour automatiser des merges.
Genre:
un fichier de description qui liste les features actives de la branches (avec A,B,C int1=A,B, int2 = A,C, …)
Merge automatique sur chaque branche lors d'un commit dans une feature.
Si ca passe nickel, sinon on corrige dans la feature branch et pas la branch d'int (pour détecter les pbs d'intégration avec d'autres features au plus tôt dans philosophie CI)
En plus vous avez un changelog gratos ….
Une belle usine à gaz ;-)
J'ai pas le temps de te faire un schéma hélas.
Mais pour que ce soit intéressant il faut CI avec déploiement continu.
Pas forcément du continuous deployment. Ceci implique que tout changement est déployé en automatique et dans la vraie vie c'est rarement le cas (sauf che les equipes de GitHub ;-)
En moins ambitieux on peut se limiter au continuous delivery. On s'assure que tout changement est potentiellement déployable.
Le déploiement effectif en recette se fait sur une base régulière qui regroupe plusieurs changement mais ne fait fait qu'officialiser la livraison. Par exemple si pratiques vraiment le continuous delivery avec Scrum, une livraison à la fin d'un sprint est presqu'un n on événement. C'est juste un tag à poser sur un commit pour satisfaire le time boxing mais rien de plus. Ca fournit des indicateurs sur la gestion de projet mais c'est tout.
Les équipes Scrum qui se limitent à la CI sont souvent confrontée à un mini effet tunnel ou on essaie de stabiliser la branche à l'arrache
avant la fin du sprint alors que le continuous delivery sécurise ça tout au long du sprint.
C'est vraiment bien expliquer dans ce post: http://kief.com/iterations-considered-harmful.html
Dans ton cas, effectivement même le continuous delivery n'est pas possible car vous n'avez pas l'assurance de la qualité.
La question est donc de savoir comment gérer au mieux l'activation sélective des fonctionnalités.
Soit par le code (feature flipping ?), soit avec des branches d'intégration.
Si vous vous limitez à une seule branche d'intégration et que vous avez besoin d'ôter une feature, tu peux reprendre à partir du dernier commit avant la feature à desactiver et rebaser les autres features par dessus. Ton approche avec des rebases+merge pour l'intégration fonctionnera très bien. (plus propre que revert amha)
Si vous souhaitez avoir plusieurs configurations de features activées différents et donc plusieurs branches d'intégration, vous devez procéder par merge pour l'intégration (sans rebase) d'une feature et ne jamais vous réaligner dedans. (merge d'une branche d'intégration vers la feature branch proscrit)
Une branche de feature reste donc isolée complètement et une fois complétée, elle est intégrée par merge dans une ou plusieurs branches
Avantage plus de souplesse pour switcher des fonctionnalités.
Inconvénient: Merge d'intégration plus conséquents (git rerere à gogo)
Sinon avec votre workflow actuel, dans mon post initial, je ne voyais pas avec ton approche par rebase comment obliger le dev à rebaser à chaque commit sur l'intégration, mais un "simple" hook pre-commit qui empêche le push de la feature branch si la base n'est pas le denier commit d'integ suffit.
Je pense que cela est dû soit à une mauvaise maitrise de git soit au fait qu'ils ont décidé de faire du travail de porc et de se foutre de l'historique (ils en ont pas encore compris la valeur)
Ou peut-être qu'une fois qu'on a publié sur une branche de feature/prototype/… partagée il est compliqué de réécrire l'historique et le repusher sans péter la conf de autres.
Après on peut toujours rappeler les bonnes pratiques avant de publier, mais une fois que le mal est fait, il faut attendre que la branche soit fermée avant de procéder au nettoyage.
On préfère alors utiliser le revert, on corrige un truc qui a fait péter la CI, …
Cela a t'il réellement un intérêt de suivre l'historique au niveau du patchset lorsque le gestionnaire de ticket fait correctement son boulot au niveau du ticket et reférence les commits asssociés.
Bref il faut appréhender la gestion de version et des demandes de changements comme un ensemble et ne pas se limiter à l'une ou l'autre.
Un historique avec des commits sans référence à des tickets ne sert pas à grand chose et vice versa
modèle de pull request moins complique que Github qui oblige à utiliser dépots (le central, le clone du chef de projet, le fork sur Github et le clone localdu fork
http://gitblit.com/tickets_overview.html
Merci de nous faire partager votre workflow qui a le mérite d'être original (en tout cas c'est la première fois que j'en vois un de ce type) et de viser la simplicité. J'ai lu avec beaucoup d’intérêt l'article détaillé.
Si j'essaie de résumer ton approche:
Une branche par fonctionnalité
Une branche d'intégration. Ceci est justifié par le fait que la recette est couteuse et qu'il faut regrouper les fonctionnalités par lots plutôt que de tester et déployer en continu (Continuous Delivery/Deployment http://kief.com/iterations-considered-harmful.html )
Une branche de prod (master) qui suit l'intégration en fast forward
Le dev d'une fonctionnalité n'est confié qu'à une personne: ceci permet de se réaligner par rebase plutôt que par merge une fois la branche partagé grâce au push --force. Ceci incombe au développeur
Pour intégrer une fonctionnalité on passe encore par un rebase avant de merger en -no--ff dans la branche d'intégration, toujours permis par le fait qu'une branche de fonctionnalité n'est sous la responsabilité que d'une seule personne à un instant donné. Pour l'intégration elle est confié à une personne qui assume le rôle d'intégrateur.
A partir de là on peut comparer aux workflows classiques:
- Celui de la pure Continuous Integration qui impose à toute l'équipe de travailler dans la même branche et d'intégrer au fil de l'eau chaque commit
- Celui que sembliez utiliser précédemment qui repose sur le même principe avec les branches par fonctionnalité mais qui procède par merge pour un réalignement et pour l'intégration sans jamais insérer l'étape du rebasing. Votre modèle est un aménagement de ce workflow me semble t'il
- Les workflows des méthodes non agiles qui ajoutent des branches de lotissement (intégration, recette, maintenance) (le SemVer que tu évoques) et qui compose entre l'approche par feature ou la pure CI pour les branche de dev. (GitFlow en est un exemple type)
Pour les diverses interrogations que tu as soulevé:
Avec une approche par fonctionnalité, le rôle d'intégrateur n'est pas obligatoire.
L'intégration peut-être confiée au développeur en l'obligeant à se réaligner dans la branche de feature avant de réintégrer juste après.
C'est ce que vous faites en demandant de rebaser sa branche avant. Ceci est plutôt malin car ça vous permet de conserver un historique lisible (nettoyé à coup de rebase -i), condensé et le plus actualisé possible par rapport à l'effort d'intégration en comparaison d'une branche de feature qui partirait d'une version stable antérieure. La contrepartie est que si vous avez moins de souplesse dans la composition des fonctionnalités. Vous ne pouvez pas maintenir en parallèle plusieurs branches d'intégration qui activerait/désactiverait certaines d'entre elles. Mais ca ne semble pas un de vos besoins.
Pour revenir sur le rôle, avec le feature branching que vous avez choisi, vous pouvez décider d'autres stratégies d'intégration. Celle que tu évoques avec un intégrateur garant de la qualité de la branche mais aussi un workflow d'approbation basé sur une revue par ses pairs.
Encore une fois donc le rôle d'intégrateur n'est pas obligatoire.
Le souci que vous rencontrez, je suppose, est plutôt lié au effets pervers du feature branching et de l'isolement qu'il permet.
Si on ne se remet pas ajours régulièrement (à chaque commit dans la branche d'intégration) on se retrouve en face d'un big bang merge au moment de l'intégration … que l'on préfère déléguer à une bonne poire qu'on nommera intégrateur ou dev senior pour lui faire avaler ce travail ingrat et délicat. Le big bang merge et la découverte tardive de problèmes d'intégration voire des conflits sémantiques (http://martinfowler.com/bliki/SemanticConflict.html) sont les arguments classiques des protagonistes de la pure CI (tous les commits dans la même branche).
Pour un bon résumé de cette question du big bang merge encore ce bon vieux Martin Fowler: http://martinfowler.com/bliki/FeatureBranch.html
A l'opposé les spécialiste de la gestion de conf prêchent l'inverse et souligne que le feature flipping reporte la complexité sur l'infra de CI en faisant exploser la combinatoire: http://www.cmcrossroads.com/article/agile-perspective-branching-and-merging
Enfin le feature flipping n'est tout simplement pas toujours possible.
Vaste débat !
Avec la CI, L'inconvénient est celui que tu évoques. Les commits de chaque fonctionnalité s'entrecroisent et la désactivation d'une fonctionnalité devient ardue si. La réponse de ces mêmes protagonistes de la CI est que le feature branching bien que facile en apparence est toujours la moins bonne solution. Il faut préférer agir au niveau du code, de l'architecture pour permettre d'activer/désactiver les features à l'exécution tout en conservant la même base de code (Une fonctionnalité est en général reportée, rarement abandonnée).
C'est la qu'il faut toujours se poser la question de savoir si on peut pratiquer le feature flipping (décrit ici http://martinfowler.com/bliki/FeatureToggle.html ), et pour les migrations techniques le branching by abstraction (http://martinfowler.com/bliki/BranchByAbstraction.html ) avant de se lancer dans les branches à tire-larigot.
Pour limiter cet isolement, il faut donc s'astreindre à se tenir à jour à chaque commit sur la branche d'intégration. Ca n'est pas de la pure CI (seuls les fonctionnalité prêtes sont integrée, celles en cours de dev restent isolée du flux d'intégration)
Avec une approche par merge, ceci peut être renforcée par le serveur de CI qui va déclencher un merge automatique à chaque commit dans l'intégration vers la feature et casser le build de la feature. Atlassian Stash et Bamboo permettent de mettre en oeuvre ceci et Atlassian investit pas mal là dessus, maas des exemples avec Jenkins existent aussi (http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow ). Ceci me parait plus compliqué voire impossible avec cette approche par rebase que tu préconises étant donné que l'historique d'une feature peut-être réécrit par le serveur de build en concurrence avec le dev. Il faut donc s'en remettre à la discipline des devs dans ce cas.
Parmi tes autres interrogations, celle de la branche de maintenance.
Ceci dépend vraiment de votre méthode de projet et du contrat qui vous lie à vos clients.
Vous pouvez incorporer à la fois des corrections de bugs et des nouvelles fonctionnalité à chaque livraison si le client est prêt à l'accepter en terme de délais, que vous êtes "sûr" de la qualité de votre code. Dans ce cas vous ne conserver qu'une unique branche continue et vous réservez les branches courtes aux hotfixes que vous n'oublierez pas de réintegrer. C'est ce qui se pratiques avec les méthodes agiles (ce qui semble être votre cas puisque tu parles de sprint)
Le mot de la fin:
Le workflow universel n'existe pas. Git Flow n'est qu'un exemple et il faut d'abord poser à plat son processus de developpement avant de se plonger dans son workflow Git. On trouve à minima un workflow par approche (séquentiel, RUP/itératif, Agile/Scrum, Continuous Delivey, …) et on doit souvent le réadapter au contexte du projet.
Les vieux dinosaures dont je suis évoqueraient ce bon vieux PGCL (Plan de Gestion de Configuration Logicielle) ou SCM Plan.
Voilà … Merci à toi si tu as eu le courage de me lire jusqu'au bout et merci encore pour ton témoignage.
Parce que le Libre, dans ses fondamentaux, défend la vie privée.
C'est quoi le Libre ?
une religion, une licorne ?
Et si je veux vendre ma vie privée pour de la gratuité, le Grand Libre doit m'en empêcher ?
Rha putain j'ai horreur des argumentations comme celle-ci ! Genre « je l'avais prédit, t'es trop con de ne pas t'en être rendu compte », c'est abjecte et complètement présomptueux. Les gens qui réfléchissent comme toi sont ceux qui font perdre le libre car ils ne se rendent pas compte de la force de leur dédain : ça ne te rend pas juste supérieur aux autres, juste pour te la péter. Non, ça a réellement un impact fort sur beaucoup de gens plus faibles qui pensent que les gens comme toi sont des mecs trop forts qui savent deviner ce qui est bien, parce que tu es « pragmatique », « réaliste », que c'est « comme ça » et que si c'est la loi du plus fort qui s'impose, « c'est normal ». C'est faux.
On attend toujours vos propositions pour assurer la pérennité de la Mofo d'une autre manière. 9a fait pas loin de 100 commentaires, ces messieurs de la morale du Libre. Mais peut*-être préfères-tu aucin LL dans la place? Ah si y'a Chromium. Faites pareil, nos amis debaineux l'ont bien fait. Et on vous attend pour pousser toutes les innovations les gars. On ne manquera pas de vous critiquer sans contribuer en bon libriste solidairres et moralisateurs.
Bref pragmatisme ou idéalisme ? Grand débat (et visiblement Zenitram s'est converti, prions ensemble mes frères)
Ah, je n'ai pas l'impression d'être vendu moi.
Ils ont fait de toi un esclave ?
Tu ne peux pas t'affranchir ?
S'ils décident de "vraiment" devenir freeware et fermer les sources tu n'as pas les sources pour repartir ?
Bref c'est juste des analogies foireuses ton truc.
Mais je pense qu'ils devraient se saborder poour faire plaisir à la bonne morale de quelques poches percées qui se parent d'un cache-sexe bien commode: L'éthique du LL.
```
Ah, le classique « c'est pas mon problème », « je n'ai rien à me reprocher », « t'es qu'un extrémiste de la vie privée », etc.
Ah les classiques donneurs de leçons de morales qui prétendent agir pour le bien de tous en voulant imposre leur choix.
Le choix tu l'as:
- Ne pas utiliser FF
- Ne pas utiliser le moteur par défaut
- Créer ton propre navigateur en repartant de la même base
- Obtenir ton ticket d'entrée à la Mofo
…
Et laisse les pauvres utilisateurs néophytes tranquille, ils ne te demandent rien et ont les mêmes libertés que toi.
Tout comme les homos n'ont rien demander aux culs-bénis, juste les mêmes droits.
Aujourd'hui, du coup, des développeurs « dépendent » du financement et « tout va s'écrouler » si on ne continue pas à les financer…
T'as raison. tu n'as qu'à les financer par des dons. C'est toujours facile de demander aux autres d'être vertueux. tu devrais revendiquer à la manif pour tous.
Peut-être que si tu arrêtes de râler, ils retireront leur moteur par défaut pour ceux qui veulent financer par le don et leur laisser leur liberté de ne pas être vendu. Quoique, tu es libre de ne pas l'utiliser ce moteur de recherche non ? Tu es libre de forker et de rebrander le truc sans artifice. Pour le coup tu iras exposer au monde comment ton altruisme en réemballant le boulot fait par les autres pour la bonne morale.
Ben non.
Ils sont pour l'impôt car ils en bénéficient. Ils sont les derniers a en payer.
La seule différence c'est qu'ils veulent bien que ce soit les autres qui payent.
Ah non !
Ca serait une attaque personnelle sinon.
Et c'est mal.
Là c'est plus pratique:
J'ai pas dit que c'était toi, si tu te sens visé c'est pas mon problème.
En tout cas, c'est pas moi.
Ça et les personnes morales, … J'adore.
Et toi DevNewton si tu ne vis pas de ta passion, fais gaffe tu fais partie des mêmes loosers que mes devs de Libre Office.
Au fait, j'adore cette vision de chose sur les attaques en géneral:
Les attaques personnelles c'est le Mal, mais heurter des minorités (qui peuvent se réduire à une seule personne, qu'en sais-tu ?) mais qu'on ne désigne pas c'est légitime.
Tu aurais pu redonner ton ressenti sans placer tes classiques attaques mais tu n'aurais pas satisfait ton égo.
Mais bon vu que le contenu n'était qu'un prétexte pour ça (y'a pratiquement rien d'autre dans ce journal) …
Rassure-toi ton public (ton futur electorat) est là !
[^] # Re: crimier!!
Posté par El Titi . En réponse au sondage La navigation privée du navigateur me sert surtout :. Évalué à 3.
Pour voir les "rapports" se réferer plus haut:
http://linuxfr.org/sondages/la-navigation-privee-du-navigateur-me-sert-surtout#comment-1581020
[^] # Re: Demande d'explications complémentaires
Posté par El Titi . En réponse au journal Crawler web & Google Sets. Évalué à 8. Dernière modification le 11 décembre 2014 à 15:27.
Un crawler c'est un un genre de « Johnny Weissmuller ». Pour ceux qui ne l'ont pas connu, il permettait, à partir d'un ou deux mouvements de bras, de générer le reste du flim.
[^] # Re: Pourquoi ?
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 6. Dernière modification le 03 décembre 2014 à 18:09.
Tu ouvres un débat intéressant.
Pour le fait de se suffire à lui-même tu te focalises encore une fois sur la gestion de version.
Un outils de gestion de version montre pourtant ses limites rapidement pour l'analyse d'impact et oblige à des stratégies de contournements.
Comment reporter une demande de changement proprement qui recouvre plusieurs commits ?
Si elle est disséminée dans plusieurs commit d'une même branche. En se basant sur l'identifiant du ticket pour cherry picker les bon commits. En isolant une fonctionnalité dans une branche au détriment de la CI, autrement …
Je ne vais pas parler entrer dans un débat sur les mérites techniques d'autres outils proprio (il est clos aujourd'hui) mais certains d'entre eux résolvent élégamment en embarquant la notion de changement comme des entité à part entière dans l'outil et permettent une gestion à un plus haut niveau.
Par exemple Perforce ou Clearcase UCM avec ses activités. L'intégration d'une activité (deliver) merge automatiquement tous les changements associés. Des contrôles sont fait pour ne pas intégrer une fonctionnalité terminée si un commit associé à une autre non complétée
Un bon outil de gestion de conf par opposition à un outil de gestion de version offre donc une intégration plus cohérente avec un outil de suivi des changements.
Encore une fois, la gestion de configuration et le suivi des demandes de changement sont si intimement liés
qu'n parle de solution de SCCM (Software Change and Configuration Mgt)
http://www.serena.com/docs/repository/solutions/GartnerMQ-SCCM-2009.pdf
Avec des outils open-sources qui ne sont pas prévus pour ça on se contente de referencer le ticket dans le commit etles comits associés dans le ticket.
Ca reste rudimentaire, peu fiable (on oublie son id de ticket on pushe et paf), pas très abouti pour la tracabilité et les reports sur d'autres branches.
Des solutions, il en existe pour le premier cas.
Avec Mylyn d'Eclipse, tu récupères tes tickets en local, tu bascules entre deux et tu commit avec le bon commentaire de tickets. (Sans parler de la gestion du contexte)
D'autres outils proposent une solution de SCCM (bug tracking + versionning) complètement distribuée et même en open-source
Fossil, Veracity (http://veracity-scm.com/)
Bref, si on met de coté les mérites techniques de Git pour automatiser certaines tâches et sa souplesse, face à ses challenger et la hormis hype portée par Linus, Git est loin d'être la meilleure option.
Ca y'est le débat Git vs (Hg|Bzr|???) est réouvert. Nostalgie !
Mais les moutons de Panurge que nous sommes doivent suivre. La guerre est terminée. Git sort vainqueur … pour le meilleur et pour le pire.
[^] # Re: Quelques retours ...
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
Et pour reprendre un peu ce que dit Gama plus bas.
Si vous maintenez plusieurs branches d'intégration, y'a peut-être des trucs à faire pour automatiser des merges.
Genre:
un fichier de description qui liste les features actives de la branches (avec A,B,C int1=A,B, int2 = A,C, …)
Merge automatique sur chaque branche lors d'un commit dans une feature.
Si ca passe nickel, sinon on corrige dans la feature branch et pas la branch d'int (pour détecter les pbs d'intégration avec d'autres features au plus tôt dans philosophie CI)
En plus vous avez un changelog gratos ….
Une belle usine à gaz ;-)
J'ai pas le temps de te faire un schéma hélas.
[^] # Re: Quelques retours ...
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
Pas forcément du continuous deployment. Ceci implique que tout changement est déployé en automatique et dans la vraie vie c'est rarement le cas (sauf che les equipes de GitHub ;-)
En moins ambitieux on peut se limiter au continuous delivery. On s'assure que tout changement est potentiellement déployable.
Le déploiement effectif en recette se fait sur une base régulière qui regroupe plusieurs changement mais ne fait fait qu'officialiser la livraison. Par exemple si pratiques vraiment le continuous delivery avec Scrum, une livraison à la fin d'un sprint est presqu'un n on événement. C'est juste un tag à poser sur un commit pour satisfaire le time boxing mais rien de plus. Ca fournit des indicateurs sur la gestion de projet mais c'est tout.
Les équipes Scrum qui se limitent à la CI sont souvent confrontée à un mini effet tunnel ou on essaie de stabiliser la branche à l'arrache
avant la fin du sprint alors que le continuous delivery sécurise ça tout au long du sprint.
C'est vraiment bien expliquer dans ce post:
http://kief.com/iterations-considered-harmful.html
Dans ton cas, effectivement même le continuous delivery n'est pas possible car vous n'avez pas l'assurance de la qualité.
La question est donc de savoir comment gérer au mieux l'activation sélective des fonctionnalités.
Soit par le code (feature flipping ?), soit avec des branches d'intégration.
Si vous vous limitez à une seule branche d'intégration et que vous avez besoin d'ôter une feature, tu peux reprendre à partir du dernier commit avant la feature à desactiver et rebaser les autres features par dessus. Ton approche avec des rebases+merge pour l'intégration fonctionnera très bien. (plus propre que revert amha)
Si vous souhaitez avoir plusieurs configurations de features activées différents et donc plusieurs branches d'intégration, vous devez procéder par merge pour l'intégration (sans rebase) d'une feature et ne jamais vous réaligner dedans. (merge d'une branche d'intégration vers la feature branch proscrit)
Une branche de feature reste donc isolée complètement et une fois complétée, elle est intégrée par merge dans une ou plusieurs branches
Avantage plus de souplesse pour switcher des fonctionnalités.
Inconvénient: Merge d'intégration plus conséquents (git rerere à gogo)
Sinon avec votre workflow actuel, dans mon post initial, je ne voyais pas avec ton approche par rebase comment obliger le dev à rebaser à chaque commit sur l'intégration, mais un "simple" hook pre-commit qui empêche le push de la feature branch si la base n'est pas le denier commit d'integ suffit.
[^] # Re: Pourquoi ?
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 3.
Ou peut-être qu'une fois qu'on a publié sur une branche de feature/prototype/… partagée il est compliqué de réécrire l'historique et le repusher sans péter la conf de autres.
Après on peut toujours rappeler les bonnes pratiques avant de publier, mais une fois que le mal est fait, il faut attendre que la branche soit fermée avant de procéder au nettoyage.
On préfère alors utiliser le revert, on corrige un truc qui a fait péter la CI, …
Cela a t'il réellement un intérêt de suivre l'historique au niveau du patchset lorsque le gestionnaire de ticket fait correctement son boulot au niveau du ticket et reférence les commits asssociés.
Bref il faut appréhender la gestion de version et des demandes de changements comme un ensemble et ne pas se limiter à l'une ou l'autre.
Un historique avec des commits sans référence à des tickets ne sert pas à grand chose et vice versa
[^] # Re: Autre alternative :Gitblit
Posté par El Titi . En réponse au journal GitLab, mais encore ?. Évalué à 2.
Sans oublier la dépêche qui me l'a fait découvrir:
http://linuxfr.org/news/sortie-de-gitblit-1-4-x
# Autre alternative :Gitblit
Posté par El Titi . En réponse au journal GitLab, mais encore ?. Évalué à 2.
C'est un projet que je suis de très près:
Enjoy …
# Quelques retours ...
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 10. Dernière modification le 03 décembre 2014 à 11:49.
Merci de nous faire partager votre workflow qui a le mérite d'être original (en tout cas c'est la première fois que j'en vois un de ce type) et de viser la simplicité. J'ai lu avec beaucoup d’intérêt l'article détaillé.
Si j'essaie de résumer ton approche:
A partir de là on peut comparer aux workflows classiques:
- Celui de la pure Continuous Integration qui impose à toute l'équipe de travailler dans la même branche et d'intégrer au fil de l'eau chaque commit
- Celui que sembliez utiliser précédemment qui repose sur le même principe avec les branches par fonctionnalité mais qui procède par merge pour un réalignement et pour l'intégration sans jamais insérer l'étape du rebasing. Votre modèle est un aménagement de ce workflow me semble t'il
- Les workflows des méthodes non agiles qui ajoutent des branches de lotissement (intégration, recette, maintenance) (le SemVer que tu évoques) et qui compose entre l'approche par feature ou la pure CI pour les branche de dev. (GitFlow en est un exemple type)
Pour les diverses interrogations que tu as soulevé:
Avec une approche par fonctionnalité, le rôle d'intégrateur n'est pas obligatoire.
L'intégration peut-être confiée au développeur en l'obligeant à se réaligner dans la branche de feature avant de réintégrer juste après.
C'est ce que vous faites en demandant de rebaser sa branche avant. Ceci est plutôt malin car ça vous permet de conserver un historique lisible (nettoyé à coup de rebase -i), condensé et le plus actualisé possible par rapport à l'effort d'intégration en comparaison d'une branche de feature qui partirait d'une version stable antérieure. La contrepartie est que si vous avez moins de souplesse dans la composition des fonctionnalités. Vous ne pouvez pas maintenir en parallèle plusieurs branches d'intégration qui activerait/désactiverait certaines d'entre elles. Mais ca ne semble pas un de vos besoins.
Pour revenir sur le rôle, avec le feature branching que vous avez choisi, vous pouvez décider d'autres stratégies d'intégration. Celle que tu évoques avec un intégrateur garant de la qualité de la branche mais aussi un workflow d'approbation basé sur une revue par ses pairs.
Encore une fois donc le rôle d'intégrateur n'est pas obligatoire.
Le souci que vous rencontrez, je suppose, est plutôt lié au effets pervers du feature branching et de l'isolement qu'il permet.
Si on ne se remet pas ajours régulièrement (à chaque commit dans la branche d'intégration) on se retrouve en face d'un big bang merge au moment de l'intégration … que l'on préfère déléguer à une bonne poire qu'on nommera intégrateur ou dev senior pour lui faire avaler ce travail ingrat et délicat. Le big bang merge et la découverte tardive de problèmes d'intégration voire des conflits sémantiques (http://martinfowler.com/bliki/SemanticConflict.html) sont les arguments classiques des protagonistes de la pure CI (tous les commits dans la même branche).
Pour un bon résumé de cette question du big bang merge encore ce bon vieux Martin Fowler:
http://martinfowler.com/bliki/FeatureBranch.html
A l'opposé les spécialiste de la gestion de conf prêchent l'inverse et souligne que le feature flipping reporte la complexité sur l'infra de CI en faisant exploser la combinatoire:
http://www.cmcrossroads.com/article/agile-perspective-branching-and-merging
Enfin le feature flipping n'est tout simplement pas toujours possible.
Vaste débat !
Avec la CI, L'inconvénient est celui que tu évoques. Les commits de chaque fonctionnalité s'entrecroisent et la désactivation d'une fonctionnalité devient ardue si. La réponse de ces mêmes protagonistes de la CI est que le feature branching bien que facile en apparence est toujours la moins bonne solution. Il faut préférer agir au niveau du code, de l'architecture pour permettre d'activer/désactiver les features à l'exécution tout en conservant la même base de code (Une fonctionnalité est en général reportée, rarement abandonnée).
C'est la qu'il faut toujours se poser la question de savoir si on peut pratiquer le feature flipping (décrit ici http://martinfowler.com/bliki/FeatureToggle.html ), et pour les migrations techniques le branching by abstraction (http://martinfowler.com/bliki/BranchByAbstraction.html ) avant de se lancer dans les branches à tire-larigot.
Pour limiter cet isolement, il faut donc s'astreindre à se tenir à jour à chaque commit sur la branche d'intégration. Ca n'est pas de la pure CI (seuls les fonctionnalité prêtes sont integrée, celles en cours de dev restent isolée du flux d'intégration)
Avec une approche par merge, ceci peut être renforcée par le serveur de CI qui va déclencher un merge automatique à chaque commit dans l'intégration vers la feature et casser le build de la feature. Atlassian Stash et Bamboo permettent de mettre en oeuvre ceci et Atlassian investit pas mal là dessus, maas des exemples avec Jenkins existent aussi (http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow ). Ceci me parait plus compliqué voire impossible avec cette approche par rebase que tu préconises étant donné que l'historique d'une feature peut-être réécrit par le serveur de build en concurrence avec le dev. Il faut donc s'en remettre à la discipline des devs dans ce cas.
Parmi tes autres interrogations, celle de la branche de maintenance.
Ceci dépend vraiment de votre méthode de projet et du contrat qui vous lie à vos clients.
Vous pouvez incorporer à la fois des corrections de bugs et des nouvelles fonctionnalité à chaque livraison si le client est prêt à l'accepter en terme de délais, que vous êtes "sûr" de la qualité de votre code. Dans ce cas vous ne conserver qu'une unique branche continue et vous réservez les branches courtes aux hotfixes que vous n'oublierez pas de réintegrer. C'est ce qui se pratiques avec les méthodes agiles (ce qui semble être votre cas puisque tu parles de sprint)
Le mot de la fin:
Le workflow universel n'existe pas. Git Flow n'est qu'un exemple et il faut d'abord poser à plat son processus de developpement avant de se plonger dans son workflow Git. On trouve à minima un workflow par approche (séquentiel, RUP/itératif, Agile/Scrum, Continuous Delivey, …) et on doit souvent le réadapter au contexte du projet.
Les vieux dinosaures dont je suis évoqueraient ce bon vieux PGCL (Plan de Gestion de Configuration Logicielle) ou SCM Plan.
Voilà … Merci à toi si tu as eu le courage de me lire jusqu'au bout et merci encore pour ton témoignage.
# Souhaitons lui bonne chance !!!
Posté par El Titi . En réponse au journal Music Information Retrieval pour hacker open source. Évalué à 2.
Visiblement, l'alternative libre à last.fm n'a pas rencontré de succès notable:
https://libre.fm/
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -2.
C'est quoi le Libre ?
une religion, une licorne ?
Et si je veux vendre ma vie privée pour de la gratuité, le Grand Libre doit m'en empêcher ?
On attend toujours vos propositions pour assurer la pérennité de la Mofo d'une autre manière. 9a fait pas loin de 100 commentaires, ces messieurs de la morale du Libre. Mais peut*-être préfères-tu aucin LL dans la place? Ah si y'a Chromium. Faites pareil, nos amis debaineux l'ont bien fait. Et on vous attend pour pousser toutes les innovations les gars. On ne manquera pas de vous critiquer sans contribuer en bon libriste solidairres et moralisateurs.
Bref pragmatisme ou idéalisme ? Grand débat (et visiblement Zenitram s'est converti, prions ensemble mes frères)
[^] # Re: Droit de parole au W3C
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -3.
Et donc ?
Tu proposes quoi ?
Qu'ils se sabordent ?
qu'il ferment leur code ?
…
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -1.
Tiens ! Tu revendiques l'éthique du libre quand ca t'arrange et dans d'autres tu t'en tiens à la définition du LL stricto-sensu.
très cohérent.
Toujours fidèle à toi même. Le discours à orientation variable toujours dans le sens qui t'arrange.
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -3.
Un couteau sous le cou ?
On t'oblige à utilser FF ? son moteur par défaut ?
Laisse moi rire. On te prend en otage, toi, personellement ? ou tous ces pauvres malheureux pour qui tu revendiques ?
Ne me prends pas en otage de ton combat. Tu me mets le couteau sous le cou.
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -3. Dernière modification le 21 novembre 2014 à 14:47.
Ah, je n'ai pas l'impression d'être vendu moi.
Ils ont fait de toi un esclave ?
Tu ne peux pas t'affranchir ?
S'ils décident de "vraiment" devenir freeware et fermer les sources tu n'as pas les sources pour repartir ?
Bref c'est juste des analogies foireuses ton truc.
Mais je pense qu'ils devraient se saborder poour faire plaisir à la bonne morale de quelques poches percées qui se parent d'un cache-sexe bien commode: L'éthique du LL.
```
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 0.
Ah les classiques donneurs de leçons de morales qui prétendent agir pour le bien de tous en voulant imposre leur choix.
Le choix tu l'as:
- Ne pas utiliser FF
- Ne pas utiliser le moteur par défaut
- Créer ton propre navigateur en repartant de la même base
- Obtenir ton ticket d'entrée à la Mofo
…
Et laisse les pauvres utilisateurs néophytes tranquille, ils ne te demandent rien et ont les mêmes libertés que toi.
Tout comme les homos n'ont rien demander aux culs-bénis, juste les mêmes droits.
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -1.
T'as raison. tu n'as qu'à les financer par des dons. C'est toujours facile de demander aux autres d'être vertueux. tu devrais revendiquer à la manif pour tous.
Peut-être que si tu arrêtes de râler, ils retireront leur moteur par défaut pour ceux qui veulent financer par le don et leur laisser leur liberté de ne pas être vendu. Quoique, tu es libre de ne pas l'utiliser ce moteur de recherche non ? Tu es libre de forker et de rebrander le truc sans artifice. Pour le coup tu iras exposer au monde comment ton altruisme en réemballant le boulot fait par les autres pour la bonne morale.
[^] # Re: C'est nous le produit ?
Posté par El Titi . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -2.
Bien évidemment, tu verses ton obole régulièrement à la Mofo pour critiquer leur conduite et tu n'es pas un simple leecher.
[^] # Re: Oui, et ?
Posté par El Titi . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à -6.
Ben non.
Ils sont pour l'impôt car ils en bénéficient. Ils sont les derniers a en payer.
La seule différence c'est qu'ils veulent bien que ce soit les autres qui payent.
[^] # Re: Oui, et ?
Posté par El Titi . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à -5.
C'est marrant, ca marche pareil avec les communistes
[^] # Re: vendredi tout est permis
Posté par El Titi . En réponse à la dépêche Meteor 1.0. Évalué à 3.
Oui
[^] # Re: 129 contacts
Posté par El Titi . En réponse à la dépêche Gajim 0.16 sort de terre. Évalué à 0.
Moi je m'appelle Rocco et si vous continuez je vous la montre
… Ma copie d'écran.
A quoi pensiez-vous ?
[^] # Re: :-)
Posté par El Titi . En réponse au journal Framasoft aurait-il tout compris?. Évalué à -3.
Ich bin ein Berliner !!!
[^] # Re: :-)
Posté par El Titi . En réponse au journal Framasoft aurait-il tout compris?. Évalué à 7.
Ah non !
Ca serait une attaque personnelle sinon.
Et c'est mal.
Là c'est plus pratique:
J'ai pas dit que c'était toi, si tu te sens visé c'est pas mon problème.
En tout cas, c'est pas moi.
Ça et les personnes morales, … J'adore.
Et toi DevNewton si tu ne vis pas de ta passion, fais gaffe tu fais partie des mêmes loosers que mes devs de Libre Office.
[^] # Re: :-)
Posté par El Titi . En réponse au journal Framasoft aurait-il tout compris?. Évalué à 1.
Au fait, j'adore cette vision de chose sur les attaques en géneral:
Les attaques personnelles c'est le Mal, mais heurter des minorités (qui peuvent se réduire à une seule personne, qu'en sais-tu ?) mais qu'on ne désigne pas c'est légitime.
Tu aurais pu redonner ton ressenti sans placer tes classiques attaques mais tu n'aurais pas satisfait ton égo.
Mais bon vu que le contenu n'était qu'un prétexte pour ça (y'a pratiquement rien d'autre dans ce journal) …
Rassure-toi ton public (ton futur electorat) est là !