Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 82 sur 182 PremièrePremière ... 3272747576777879808182838485868788899092132 ... DernièreDernière
Affichage des résultats 2 431 à 2 460 sur 5435
  1. #2431
    Citation Envoyé par William Vaurien Voir le message
    on a un Jenkins, et je trouve ça un peu pourri aussi:
    tout dépend de plugins à la docs lacunaires, le DSL en groovy pour les pipelines est une horreur sans nom, bref c'est la peste et le choléra pour moi ces usines de build...
    Essaye de passer au pipeline déclaratif au lieu d'utiliser Groovy, c'est un peu moins l'enfer comme ça.

    When Jenkins Pipeline was first created, Groovy was selected as the foundation. Jenkins has long shipped with an embedded Groovy engine to provide advanced scripting capabilities for admins and users alike. Additionally, the implementors of Jenkins Pipeline found Groovy to be a solid foundation upon which to build what is now referred to as the "Scripted Pipeline" DSL. [2].

    As it is a fully featured programming environment, Scripted Pipeline offers a tremendous amount of flexibility and extensibility to Jenkins users. The Groovy learning-curve isn’t typically desirable for all members of a given team, so Declarative Pipeline was created to offer a simpler and more opinionated syntax for authoring Jenkins Pipeline.


    Both are fundamentally the same Pipeline sub-system underneath. They are both durable implementations of "Pipeline as code." They are both able to use steps built into Pipeline or provided by plugins
    - La version 3 est arrivée !

  2. #2432
    Citation Envoyé par Frypolar Voir le message
    T’as le droit de faire en sorte que ce compte soit utilisé par un service ? Je ne connais pas l’API de GitLab mais si c’est autorisé, tu peux faire un petit service qui ajoute les reviewers requis et n’approuve que quand suffisamment de reviewer requis ont approuvé.
    A priori tu peux : https://docs.gitlab.com/ee/api/merge...html#update-mr

    Leur API est vraiment trèèèès fournie, tu peux faire quasiment tout.
    Par contre si tu veux l'API dédiée à l'approbation des merge-request (https://docs.gitlab.com/ee/user/proj...approvals.html) forcément faut que t'ai la version payante.

    Mais juste avec la première requête citée, en mettant à jour "assignee_id" tu dois pouvoir faire le nécessaire.

    Et ça devient vraiment sympa si tu combines ça avec un bot slack qui vient prévenir automatiquement les utilisateurs en question qui doivent faire la review (perso on a juste un message dans le chan dédié au projet qui prévient de l'ouverture de la merge-request vu que tout le monde peut faire la review).

    Citation Envoyé par TwinBis Voir le message
    Essaye de passer au pipeline déclaratif au lieu d'utiliser Groovy, c'est un peu moins l'enfer comme ça.
    Je confirme, la syntaxe déclarative est plus digeste.
    Et avec l'interface blue-ocean ça donne une visualisation assez sympa des builds contenant plein de stages.

    Par contre ouais les plugins sur Jenkins c'est un peu l'enfer à gérer, mais en vrai y'en a juste quelques un de vraiment utiles.

    A noter que Gitlab CI fait quasiment la même chose maintenant.

    Citation Envoyé par William Vaurien Voir le message
    Et puisque c'était "Atlassian c'est de la merde" et pas juste bitbucket, il y a quoi de vraiment bien à mettre en face de Jira/Confluence/Bamboo ?
    Jira c'est clairement dur de trouver une bonne alternative.
    Confluence idem mais c'est pas utilisé partout.
    Bamboo j'ai jamais testé.

    Après j'aimerais bien tester tout le toolkit de Jetbrains à ce niveau, mais je l'ai encore jamais vu chez un client.
    C'est la faute à Arteis

  3. #2433
    Wouf, je pensais pas déchainer les foules avec mes questions
    La raison pour laquelle on paye, c'est pour les features :
    - Le poids des US
    - Burndown
    - Le fait pouvoir configurer les boards
    - Webhook
    et j'en oublie surement.

    Ces features sont gratuites sur la CE ? De ma compréhension, les limitations sont les même que Gitlab classique.

  4. #2434
    Pareil, le toolkit de Jetbrains fait envie, mais jamais vu l'ombre d'une installation...

    Pour Jenkins je suis coincé avec une vieille version (je suis pas admin) et la nouvelle version est pour le moment réservée au "projets_microservices_angular_avec_docker_tasvu". ..
    Les projets sur cette mouture utilise un framework très rigide mais qui est intéressant: git-workflow + sonar avec quality gate + livraison automatique par palier jusqu'en prod.

    Et notre projet ne rentre pas encore dans les clous du trucs. C'est la partie micro-service qui coince dans mon équipe.

    C'est une volonté partagé par toute l'équipe (devs et chefs de projet) mais c'est tellement à la mode que le reste de l'entreprise fonce dedans, des fois de manières justifié, des fois vraiment pas...
    D'ailleurs c'est devenu un blague récurrente dans mon équipe et le mot micro-service déclenche des rires nerveux.
    Et bon je vois l'équipe d'à côté avec ses 8 microtrucs pour afficher un pauvre formulaire web, c'est quand même pas mal de galère pour pas beaucoup d'intérêts (j'en trouve plein des intérêts, mais c'est loin d'être justifié partout).

    C'est pareil chez vous aussi ?

  5. #2435
    Pas partout, mais je confirme pour l'avoir vu que quand la peste micro-services est en place, y reste plus qu'à amputer

  6. #2436
    Citation Envoyé par wafwafe Voir le message
    Wouf, je pensais pas déchainer les foules avec mes questions
    La raison pour laquelle on paye, c'est pour les features :
    - Le poids des US
    - Burndown
    - Le fait pouvoir configurer les boards
    - Webhook
    et j'en oublie surement.
    Ah oui mais là vous commencez à utiliser la partie gestion de projet qui serait sur un Jira habituellement.
    Et effectivement tu trouveras pas d'alternative gratuite à ça.

    Citation Envoyé par William Vaurien Voir le message
    Pour Jenkins je suis coincé avec une vieille version (je suis pas admin)
    Va filer des taquets à ta DSI.


    Pour ceux qui n'ont jamais testé, Jenkins Blue Ocean ça ressemble à ça : https://www.silicon.fr/wp-content/up...an-Jenkins.png
    Sauf que tout est configurable via un fichier de config versionné avec le code de ton projet (exit donc les configurations manuelles de Jenkins chiantes comme la mort).

    Citation Envoyé par William Vaurien Voir le message
    C'est pareil chez vous aussi ?
    Pas trop mais j'ai vu ça chez certains clients.

    L'architecture micro-services peut être très utile dans les bons cas et si bien utilisée, sinon c'est vraiment contre-productif et très contraignant.

    Par contre :
    Citation Envoyé par William Vaurien Voir le message
    angular_avec_docker_tasvu
    Ça c'est très bien.
    Tout l'environnement de build doit être dockerisé.
    Pareil pour l'environnement d'exécution.

    Citation Envoyé par William Vaurien Voir le message
    Les projets sur cette mouture utilise un framework très rigide mais qui est intéressant: git-workflow + sonar avec quality gate + livraison automatique par palier jusqu'en prod.
    Le continuous delivery c'est le bien, mangez en.
    Git-flow aussi.
    C'est la faute à Arteis

  7. #2437
    Citation Envoyé par vectra Voir le message
    Pas partout, mais je confirme pour l'avoir vu que quand la peste micro-services est en place, y reste plus qu'à amputer
    Idem.
    Ce qui m'attriste, c'est de constater que des collègues considèrent que monolithique = non modulaire, et micro-services = justement c'est modulaires, c'est fait pour (et puis bon, dire "Spring Cloud" ou "Kubernetes" dans une phrase ça permet de se la péter à la cantine).
    Alors qu'un monolithique ça se modularise super bien, et le passage au micro-services implique 1/ d'apprendre de nouveaux concepts, avec encore peu de collègues qui ont de l'xp et les bonnes pratiques, donc faire des conneries 2/ une complexification de l'archi et des méthodes de test 3/ des coûts non négligeables (Martin Fowler a d'ailleurs rédigé/linké un excellent article sur le sujet). Et puis l'intérêt premier des micro-services c'est pas d'être modulaire. Mais bon, je parle de jeunes ingés en SSII qui sortent de l'école, ne sont pas curieux, et qui se prennent pour les rois du monde.
    Notre monolithique ronronne depuis 5 ans, j'attends de voir la tronche du projet en micro-services d'à côté

  8. #2438
    Git Flow c'est pratique dans certains cas, mais quand le projet le permet (c'est à dire équipe + projet suffisamment propre) le mieux c'est quand même de faire du trunk based development.
    Alors forcément il faut des test et du CI/CD, mais quand ça tourne c'est beaucoup plus confortable et efficace.
    - La version 3 est arrivée !

  9. #2439
    L'intérêt du micro-péniservice, c'est pas de tout balancer sur Amazon AWS?
    Mais bien entendu, on garde notre Atlassian en local pour pas se faire voler par les chinois du FBI (ça sera Amazon, comme ça).

  10. #2440
    Git-flow j'aime bien, mais il y a ds zones d'ombre sur la gestion des branches quand tu livres et démarres une nouvelle feature. Donc 90% git-flow yes, mais les 10% sont à bien préparer pour ne pas se retrouver avec une version foirée livrée en prod et l'impossibilité de rolllback sur la v -1.
    En tous cas on l'a challengé il y a peu, et git-flow ne donnait pas de bonne réponse. Ceci dit, notre CP voulait plusieurs sprints en parallèle (v1 en prod, v2 en dev, v3 aussi en même temps, et un patch v1.1), une horreur à gérer, et pas sûr qu'il existe une solution.

  11. #2441
    Citation Envoyé par Orhin Voir le message
    Ah oui mais là vous commencez à utiliser la partie gestion de projet qui serait sur un Jira habituellement.
    Et effectivement tu trouveras pas d'alternative gratuite à ça.
    Depuis le début, on parle d'Atlassian (Bitbucket/Jira/Confluence*), pas de Bitbucket seul
    J'ai jamais utilisé le burndown perso, mais mes encadrants, oui... ().

  12. #2442
    Citation Envoyé par vectra Voir le message
    L'intérêt du micro-péniservice, c'est pas de tout balancer sur Amazon AWS?
    Mais bien entendu, on garde notre Atlassian en local pour pas se faire voler par les chinois du FBI (ça sera Amazon, comme ça).
    Tu peux même faire du serverless self-hosté, je sais pas trop comment quelqu'un en arriverait là mais c'est possible

  13. #2443
    Citation Envoyé par Orhin Voir le message
    Ah oui mais là vous commencez à utiliser la partie gestion de projet qui serait sur un Jira habituellement.
    Et effectivement tu trouveras pas d'alternative gratuite à ça.
    Ça marche, merci

  14. #2444
    Citation Envoyé par gros_bidule Voir le message
    Ceci dit, notre CP voulait plusieurs sprints en parallèle (v1 en prod, v2 en dev, v3 aussi en même temps, et un patch v1.1), une horreur à gérer, et pas sûr qu'il existe une solution.
    Change de CP.
    - La version 3 est arrivée !

  15. #2445
    Citation Envoyé par Orhin Voir le message
    Le continuous delivery c'est le bien, mangez en.
    Git-flow aussi.
    Si par Git-flow tu parles de ça alors c’est incompatible avec continuous integration/deployment/delivery. Par définition, ce sont des concepts opposés. Si tu cibles CI/CD alors tu dois faire du trunk based development. Là aussi par définition. Sinon c’est juste une illusion de la même manière que tous ces outils de CI sont une illusion. Ce sont des outils de build automatique et ça ne suffit pas pour l’intégration continue. Enfin, suivant ton échelle c’est même pas nécessaire d’avoir un build automatique pour faire de l’intégration continue. C’est quand même plus confortable avec.

  16. #2446
    D'ailleurs, quand on parle de Continous Integration, on met souvent en pratique de la Continuous Integration Theatre.
    Il existe des nuances importantes, si vous n'avez pas été sensibilités au sujet, ce qui vous permettra de vous questionner sur votre système d'inté.

    Citation Envoyé par TwinBis Voir le message
    Change de CP.
    J'ai finit par changer de boite, plus pratique

  17. #2447
    trunk based development c'est quand t'es coincé avec CVS ? En tout cas ça y ressemble fortement...
    dans mon équipe on a un espèce de git-flow (sans l'outil en ligne de commande, mais en reprennant la structure) avec des "features branches" et des pull request / revues de code light (très bien intégré au passage avec Jira et Bitbucket).

    Le workflow de revue est informel: tout le monde est en revue de code et tout le monde peut valider une demande. En pratique un dev peut forcer ses changements en cas d'urgence ou s'il juge qu'il n'y a pas de risque.

    Même mes collègues qui étaient resté collé à CVS pendant des décennies ne reviendraient pas en arrière.

    Pourquoi ce système ne serait pas approprié et serait une illusion ? En lisant en diagonale la doc que tu colles en lien, je vois pas trop en quoi le 'trunk-based dev' serait seul du vrai CI ...

  18. #2448
    Citation Envoyé par gros_bidule Voir le message
    "Kubernetes"
    Tu peux tout à fait utiliser Kubernetes sans faire du micro-services ceci-dit.

    Citation Envoyé par vectra Voir le message
    Depuis le début, on parle d'Atlassian (Bitbucket/Jira/Confluence*), pas de Bitbucket seul
    J'ai jamais utilisé le burndown perso, mais mes encadrants, oui... ().
    Relis la discussion, le monsieur auquel je répond paie pour Gitlab Cloud, pas pour Atlassian.

    Citation Envoyé par Frypolar Voir le message
    Si par Git-flow tu parles de ça alors c’est incompatible avec continuous integration/deployment/delivery. Par définition, ce sont des concepts opposés.


    Ton intégration continue elle tourne sur toutes tes branches (master, develop, features, hotfix, release).
    Ton déploiement continu tu le fais en permanence sur toutes les branches "stables" (master, develop) et sur les branches de courte durée (feature, hotfix, release) dès qu'elles entrent en merge-request.
    Et ta livraison continue tu le fais en permanence à partir de master.

    Du coup j'ai du mal à voir l'incompatibilité.

    Au passage, pour présenter git-flow je préfère ce site : https://danielkummer.github.io/git-f...dex.fr_FR.html

    Citation Envoyé par gros_bidule Voir le message
    ne pas se retrouver avec une version foirée livrée en prod et l'impossibilité de rolllback sur la v -1.
    Comment ça impossibilité de rollback ?
    Si tu parles de version livrée, bah tout est tagué donc tu peux facilement regénéré un nouveau build à partir d'une ancienne version.
    Surtout que si t'as chaine d'inté est bien foutue t'as de toute façon les artefact disponibles des anciennes versions (sur Jenkins + Nexus ou hub Docker).

    Si tu parles au niveau codebase, bah dans ce cas faut faire une branche hotfix qui contient les correctifs nécessaires (donc potentiellement l'invalidation de modifications précédentes) et tu la merge dans master + develop.

    Citation Envoyé par gros_bidule Voir le message
    En tous cas on l'a challengé il y a peu, et git-flow ne donnait pas de bonne réponse. Ceci dit, notre CP voulait plusieurs sprints en parallèle (v1 en prod, v2 en dev, v3 aussi en même temps, et un patch v1.1), une horreur à gérer, et pas sûr qu'il existe une solution.
    Ouais le gros point noir c'est quand tu dois supporter plusieurs versions majeurs en même temps.

    Dans ce cas la seule solution c'est d'avoir plusieurs branches master (une pour chaque "vieille" version + la branche master par défaut pour la dernière version majeure).
    Tant que tu dois faire que du fix pour les anciennes versions, ça reste acceptable.
    C'est la faute à Arteis

  19. #2449
    Pas con les multiples master. Je note cela ! (pendant plusieurs années ce sont nos branches de features qui étaient renommées en des branches de prod - ce qui revient à plusieurs master finalement, donc on se les traînaient longtemps, puis un jour pouf, nouveau CP, nouvelles règles)

  20. #2450
    Citation Envoyé par gros_bidule Voir le message
    Pas con les multiples master. Je note cela ! (pendant plusieurs années ce sont nos branches de features qui étaient renommées en des branches de prod - ce qui revient à plusieurs master finalement, donc on se les traînaient longtemps, puis un jour pouf, nouveau CP, nouvelles règles)
    Après t'as une autre approche possible : si tes versions majeures sont vraiment différentes et très espacées dans le temps (genre +1 an d'écart entre chaque) rien n'empêche d'avoir plusieurs repo git (à chaque version majeure tu fais un fork) qui obéissent chacun à git-flow.

    Ça a l'avantage de permettre de plus facilement ajouter des nouvelles fonctionnalités aux anciennes versions.
    Par contre c'est plusieurs chiant pour répercuter les correctifs qui concernent toutes les versions.

    PS : j'ai édité mon post précédent pour te répondre sur un autre point
    C'est la faute à Arteis

  21. #2451
    Citation Envoyé par William Vaurien Voir le message
    trunk based development c'est quand t'es coincé avec CVS ?
    Non pas du tout ! Ça fonctionne très bien avec Git. L’important c’est de ne créer des branches qu’à partir de master et de ne merger les branches que dans master. Pas le droit de faire des branches de branches.

    Citation Envoyé par Orhin Voir le message


    Ton intégration continue elle tourne sur toutes tes branches (master, develop, features, hotfix, release).
    Ton déploiement continu tu le fais en permanence sur toutes les branches "stables" (master, develop) et sur les branches de courte durée (feature, hotfix, release) dès qu'elles entrent en merge-request.
    Et ta livraison continue tu le fais en permanence à partir de master.

    Du coup j'ai du mal à voir l'incompatibilité.

    Au passage, pour présenter git-flow je préfère ce site : https://danielkummer.github.io/git-f...dex.fr_FR.html
    Ce que tu décris est un continuous build. Je sais que c’est souvent appelé continuous integration mais c’est faux. Ça participe au continuous integration theater qu’a mentionné gros-bidule. Si tu restes longtemps (plusieurs jours) sur une branche en pensant être tranquille grâce à ton build, alors tu te trouves dans un cas de continuous isolation.

    Pose-toi ces trois questions :
    • Est-ce que tous vos développeurs poussent leurs changements sur une branche commune (typiquement master) au moins une fois par jour ?
    • Est-ce que chaque commit déclenche un build avec des tests automatiquement ?
    • Quand le build sur master pète, est-il corrigé en moins de 10 minutes ?


    Si tu réponds non à une question ou plus alors tu ne fais pas d’intégration continue.

    L’intégration continue est très à la mode, les gens veulent donc suivre la mode. Sauf que réellement suivre les principes de l’intégration continue c’est dur. Vraiment dur. Alors les gens font semblant, consciemment ou pas, pour rejoindre le club. Pareil avec les outils d’intégration continue. C’est plus facile de mentir pour vendre ton produit. En vrai, jamais un outil ne suffira à faire de l’intégration continue vu que c’est avant tout une pratique. Tout ça participe au détournement du terme.

    Ça semble hyper arbitraire mais, en réalité, l’intégration continue est un procédé complètement arbitraire. Ça a été défini par une équipe dans les années 90 parmi d’autres procédés. Comme ça marchait bien ils en ont parlé, beaucoup. Si tu espères bénéficier des mêmes avantages qu’eux alors tu dois suivre leurs principes. Si tu ne les suis pas tu ne fais pas de l’intégration continue, tu fais autre chose. Ça peut être très bien hein, seulement il serait faux d’appeler ça « intégration continue ».

    Et en réalité, très très peu de gens font vraiment de l’intégration continue. Déjà il faut demander à des humains de changer de façon de travailler. Typiquement quand tu dis qu’il faut merger ses changements dans master au moins une fois par jour on te répond que c’est impossible ou que ça ralentirait trop le développement. Aucune branche ne doit durer plus de 24h. Rien qu’à lire ça je pense que tout le monde ici, ou presque, va penser ça. T’es aussi censé utiliser un monorepo donc là aussi on te dit que c’est impossible/trop lent. Tu dois avoir énormément de tests, pareil « ça va trop ralentir le dev ».

    L’intégration continue est une pratique drastiquement éloignée d’autres modèles (comme GitFlow) et, je trouve, assez contre-intuitive en première approche. C’est comme le « if it hurts, do it often ». J’ai mis un peu de temps à comprendre, à première vue ça a l’air complètement con.

    Des liens intéressants :
    https://martinfowler.com/articles/co...tegration.html (par un membre de l’équipe à l’origine du Xtreme programming d’où provient l’intégration continue)
    https://martinfowler.com/bliki/Conti...ification.html avec un lien vers une vidéo qui montre que 99% des gens répondent non à au moins une des questions.
    https://trunkbaseddevelopment.com/

  22. #2452
    Citation Envoyé par vectra Voir le message
    Je comprends pas bien.
    blabla
    Ok, je vais voir si j'arrive à un truc sympa en pur CMake

  23. #2453
    Donc on fait du trunk based dev suivant ta définition.

    Par contre c'est quoi l'explication rationnelle pour la durée de vie des branches ?

    En tout cas ces articles sont intéressant dans le fond, mais ont le côté pinaillage et guerre de chapelles que j'apprécie de moins en moins dans le milieu des dev.
    Et la manière dont c'est repris tel quel sans contextualiser renforce le côté dogmatique.

    Est-ce que la taille du projet et/ou équipe ne devrait pas rentrer en compte également ?
    Bah oui sit tu es dans une équipe de centaines de personnes sur un très gros système, c'est sûr que si tu traînes à merger ta branche tu t'exposes à des difficultés et tu risques de tout péter.
    Maintenant dans une équipe de 3 personnes qui montent un "petit" projet, tout de suite le merge non-journalier aura moins d'impact.

    Ton appli c'est facebook ? Un truc gargantuesque qui est permanent mis à jour et constamment enrichi ? ou plutôt un petit back-office pour une centaine d’utilisateurs allergiques aux changements pour lesquels tu fais une version mineur par mois et une majeur tous les 2 ou 3 ans ? Ou bien est-ce un soft vendu avec du support pour lequel tu dois maintenir plusieurs versions en parallèle ?

    Bref c'est un peu jouer sur les mots que de faire autant de distinctions et de décerner des certificats bons points par rapport à ton usage.

    Et question bonus, tu fais comment en pratique quand un dev prend plus de temps qu'une journée, par exemple parcequ'un changement pète une série de tests et que tu découvre que ton "petit changement" rapide à des effets de bords non prévus ? (on ne fait pas tous du micro service). Et si tu fais un peu de R&D ? Genre un truc au long terme que tu bricoles de temps en temps ? Ou si tu intègres un truc un peu coton que tu maîtrises mal (genre la sécurité pour moi) et qui te demande un peu plus de temps que prévu pour intégrer et tester ?

    Bref, moi je suis content quand j'arrive sur un projet avec un CP pragmatique qui veut du test (unitaire, intégration, avec ou sans mock, en vrai base ou en base mémoire), de la couverture de code (mais pas 100%, raisonnée la couverture de code), des builds automatisés (avec un build la nuit bien suffisant si on ne livre pas tous les jours) et des déploiements automatisés.

    Et puis ce Martin Fowler, là c'est pas lui le chantre de l'UML et Ruby ? C'est un peu la lose quand même
    (en vrai je l'aime beaucoup ce Monsieur, hein, même si je prêtais beaucoup plus attention à lui vers 2005 / 2010, j'ai l'impression qu'il est plus discret maintenant ?)
    Dernière modification par William Vaurien ; 22/08/2019 à 23h03.

  24. #2454
    Dans le même genre, vous pensez quoi de Gerrit ? Perso j'ai du mal ...

  25. #2455
    Citation Envoyé par Kamikaze Voir le message
    Ok, je vais voir si j'arrive à un truc sympa en pur CMake

    J'ai probablement pas fait ça aussi bien qu'il aurait fallu, mais ça se fait couramment en CMake.

  26. #2456
    Citation Envoyé par vectra Voir le message

    Code:
    include_directories( ${myvtk_INCLUDE_DIRS} )
    link_directories( ${myvtk_LIBRARY_DIRS} )





    Amateur du CMAKE!!!
    On ne met pas les include en global comme ca, mais on utilise target_include_directories afin de pas pourrir son environnement de build de millions de dossier d'include additionnels qui ne servent que pour une target. Idem pour les link!

    Un peu de lecture :
    https://pabloariasal.github.io/2018/...o-cmake-right/
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  27. #2457
    Citation Envoyé par William Vaurien Voir le message
    Donc on fait du trunk based dev suivant ta définition.

    Par contre c'est quoi l'explication rationnelle pour la durée de vie des branches ?
    Et question bonus, tu fais comment en pratique quand un dev prend plus de temps qu'une journée ?
    Je sais pas si tu parles du principe général de branche courte ou de la durée d’un jour donc je vais répondre aux deux.

    Pour l’idée générale, un principe fondamental de l’intégration continue est d’éviter que les gens ne s’éloignent trop les uns des autres. Plus tu restes longtemps sur une branche, plus le retour sur master sera difficile. Tes modifications seront peut-être obsolètes ou tu peux te taper un conflit pas rigolo. De plus tes collègues peuvent dépendre de tes modifications pour avancer. Sur des branches qui durent des jours, des semaines voire des mois, tu peux arriver à un joli bordel de branches puis à un joli bordel de merge.

    Si, malgré tout, tu arrives à faire ton merge vers master, tu risques aussi d’emmerder tes collègues qui veulent mettre leur branche à jour ou à leur tour merge vers master. À cause de l’importance de tes modifications tu risques aussi de perturber la stabilité du code. Quand tu veux être certain de la qualité de ton code à tout moment pour pouvoir livrer n’importe quand, tu n’aimes pas l’instabilité.

    Donc, en gros, avec l’intégration continue on veut absolument éviter les gros merge donc on veut des branches de développement courtes. C’est donc une approche totalement opposée à Git Flow. Après, à chacun de voir si ces problèmes en sont pour eux ou si l’approche de l’intégration continue est la meilleure solution.

    Pour la durée exact, c’est arbitraire. En fait, dans le bouquin de Kent Beck qui explique brièvement le principe pour la première fois, il est écrit :
    Integrate and test changes after no more than a couple of hours.
    Seulement, à l’époque, les outils de build automatique sur un serveur distant, ça n’existait pas. Eux ils prenaient leurs modifs et allaient sur l’ordinateur dédié à l’intégration pour appliquer leur patch et lancer le build. Exemple ici. C’est pas la même équipe mais ça donne une idée et ça montre aussi que l’intégration continue n’est pas une question d’outil CI. J’imagine que le faire toutes les heures permettait d’éviter des bouchons en fin de journée.

    Les outils de CI type Jenkins ont commencé à apparaître ensuite. Il me semble que le premier a justement été fait par d’anciens membres de l’équipe à l’origine de l’intégration continue.

    Pour en revenir à la durée d’une journée je pense que c’est à peu près le temps limite avant que le risque de dérive ne soit trop grand. Si tu bosses plus d’une journée sur la même branche, il y a des chances que tu sois en train de t’embarquer dans un truc trop gros. De plus, avoir une durée fixe aide à faire passer le message. On m’a déjà parlé de « branches courtes » de deux semaines...

    Et pour ta dernière question, il faut que tu découpes plus finement tes tâches. C’est juste un coup de main à prendre. Tu peux aussi t’aider de techniques comme les branches par abstraction. C’est particulièrement pratique pour les gros refactoring. Quand on a l’habitude de Git Flow ou similaire, il faut aussi se sortir de la tête que seule une feature complète peut aller dans master. Ça aussi c’est un coup de main à prendre. L’important est que la modif soit couverte par un build et des tests automatiques lancés dès qu’on touche à master.

  28. #2458
    Merci pour ta longue explication très pédagogique. Disons que c'était de ma part une question plutôt centré sur la durée d'une journée que sur la raison des branches courtes.

    Comme évoqué dans mon post précédent, les effets d'une branche plus longue seront variables suivant la physionomie du projet.
    Une branche d'une semaine n'aura pas la même 'fraîcheur' dans une équipe de cent personne avec une cinquantaine de merge/jour que dans une équipe de 3 personnes avec une poignée de merge/semaine.

    Et perso j'en ai jamais vu des projets avec cent personnes. Le max c'était une douzaine, et c'était d'une part ponctuel et d'autre part très segmenté: équipe backend, équipe frontend, équipe intégration avec les autres applis.

    Je ne veux pas imposer mon point de vue, c'est comme dit plus haut, une petite exaspération de ma part venant d'une part des "lobbyistes forcenés" qui prennent des dogmes et veulent les appliquer sans discernement, et de l'autre les wanabee qui veulent appliquer à tout prix des concepts à la mode sans vraiment les comprendre (genre faire de l'Agile; faire du devops, faire du serverless, etc).
    Je ne range personne du forum dans ces catégories, c'est plutôt de l'expérience perso (et un peu les tirades ayatollehsque sur "ton intégration continue elle pas canon" quand même).
    Au final je m'en fout de faire de la vrai CI, mon but est d'avoir un workflow qui convienne aux dev ET au projet.

    Pour l'argument sur la divergence, je suis globalement d'accord, mais je modulerais quand même pas mal les risques.
    Dans le cadre de projet de taille moyenne (qui doivent représenter un bon 80% de tous les projets au pifomètre) il n'y a pas tant de "collisions" de code que ça: chaque 'feature' demande bien souvent de toucher à des trucs assez distinct dans le projet, et s'il y en a plusieurs en même temps c'est souvent le même dev qui prend le paquet. Dans ces conditions les merges foireux avec conflits de code abominable deviennent plutôt rare. Et quand ça arrive il suffit bien souvent de faire une revue de code avec l'autre dev impacté pour résoudre les problèmes. Si les bonnes pratiques de base de découpage des méthodes en petits blocs d'une vingtaine de lignes max sont appliqué, les chances de conflits sont encore réduite...

    Il est de plus assez facile synchroniser une branche qui traîne un peu dans le temps avec la branche principale. Donc de voir venir les problèmes éventuels et de les corriger avant d'être noyé sous une éventuelle accumulation.

    Donc il n'y a pas vraiment plus de risque d'instabilité qu'avec des merge frénétiques. Qui induisent sûrement leurs lots de problèmes également.
    Je suis par exemple quasi certain que des features flags sont ainsi ajoutés pour 'faire son merge' dans les temps.
    Voici un rapport qui, entre autre, souligne ce genre de difficultés: http://publications.lib.chalmers.se/...573/220573.pdf (j'ai touvé ça sur la page de wikipedia de l'intégration continue)

    Pour la citation de Kent Beck, j'ai l'impression que la durée 'couple of hours' concerne plutôt le temps que tu mets à mettre ta branche principale en ordre après un merge.

    En effet aujourd'hui ça prend quelques secondes avec git, le tout normalement validé en quelques minutes par un analyseur de code et des tests, et le merge est fait en amont sur la branche temporaire.
    Par contre dans 'l'ancien temps', comme tu l'as souligné, c'était une autre paire de manche. La compilation pouvait prendre plusieurs heures, les tests n'étaient pas légion, l'analyse était limitée aux warning (et encore).
    Et les outils de gestion de version de l'époque n'étaient pas très amicaux avec les branches. Sans oublier que les méthodes faisaient bien souvent des centaines de lignes, si ce n'est des milliers...
    Un dev qui commitait ses changement comme un goret dans le master pouvait donc tout bloquer pendant plusieurs heures pour une bête erreur de syntaxe commité par erreur...

    Le découpage des tâches, dans mon équipe ne se fait pas à un tel niveau de détail, car nous n'en éprouvons pas le besoin. Notre projet ne doit pas être livré en continue, mais par à coup.
    Par contre notre méthode de travail nous assure que la branche 'trunk' est toujours livrable (on pourrait donc faire de la livraison continue).
    Nous n'avons pourtant jamais ressenti le besoin de faire des branches à durée de vie plus courte. Nos branches ont la durée de vie nécessaire au rythme de notre projet.

    Quel est le but de mon message ? Peut être que vouloir être dogmatique est contre productif ? Que ça détourne des personnes intéressées mais qui ont l'impression d'être face à des psycho-rigide dogmatiques et qu'il vaut mieux aller voir ailleur ?
    Quand on donne une boite à outil à une équipe (agile, CI, devops, micro service), le meilleur moyen, à mon avis, de les en dégoûter c'est d'être trop orthodoxe !

    Vouloir à tout pris faire comme le gourou l'a dit en prenant les x points de son manifeste au pied de la lettre sans considérer le contexte ne me semble pas être très constructif.
    D'ailleurs à la base de ces méthodologies, ce sont bien souvent des principes, qui devrait idéalement inspirer les équipes pour qu'elles se les approprie et en tire le mieux et le plus possible sans que ça devienne un fardeau.

    Et j'ai vu des équipes complètement plombées parce que du jour au lendemain il fallait appliquer tel ou tel principe suivant l'avis d'un quelconque expert (en communication ?) parce que c'est à la mode.

    L'agile au chausse-pied et version big-brother en est pour moi un très bon exemple datant de mes années de 'consultant' (vers 2010 pour moi).
    Et aujourd'hui il y a un peu le même phénomène avec les micro-services servis à toutes les sauces !

    Et donc est-ce que c'est bien la peine de faire de l'orthodoxie sur l'intégration continue ?

  29. #2459
    Citation Envoyé par William Vaurien Voir le message
    Et donc est-ce que c'est bien la peine de faire de l'orthodoxie sur l'intégration continue ?
    Totalement d'accord avec toi. Le but de l'intégration continue est clair : améliorer la productivité et limiter les risques (régression, allongement des délais). Mais la méthode optimale pour y parvenir dépend d'énormément de facteurs. En premier, l'équipe ; sa taille, son organisation et sa maturité rendrons pertinents certains principes orthodoxes de CI, mais d'autres seront contre-productifs voire toxiques à appliquer. Puis le projet, sa taille, sa nature et le rythme des releases posent des contraintes spécifiques. Tous ces facteurs cumulés rendent chaque projet pour ainsi dire unique, et appliquer une recette unique - la tentation du « marteau en or » omniprésente en génie logiciel - va à l'encontre d'un des principes fondamentaux du développement, qui est l'adaptation. Tout au plus peut-on énoncer des principes très généraux, sans perdre de vue l'objectif visé, et les mettre à sa sauce.

  30. #2460
    Question: qu'est-ce qui différencie Python des autres langages ?
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •