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.
[^] # 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.