GitLab 8.11 : vue kanban et bien plus

Posté par . Édité par Davy Defaud, ZeroHeure, Benoît Sibaud, Nÿco, olivierweb et palm123. Modéré par Benoît Sibaud. Licence CC by-sa
43
20
sept.
2016
Communauté

Tous les 22 du mois, une nouvelle version de la forge logicielle Gitlab (Community Edition pour la version libre et Enterprise Edition pour la propriétaire) est publiée. Celle‐ci est très grosse et contient notamment une fonctionnalité attendue : une vue kanban pour les tickets.

GitLab

GitLab.com a été mis à jour : dépôts illimités publics ou privés, importation depuis d’autres forges, miroir sur ou depuis GitHub, pages GitLab pour votre site, solution d’intégration continue…

Les changements majeurs

Vue kanban pour les tickets

Cette méthode présente les tickets sous des colonnes, par exemple : « à faire », « en développement », « en test », « prêt » ou « déployé ».

Illustration :
gitlab issue board

Présentation vidéo :
https://www.youtube.com/watch?v=UWsJ8tkHAa8

Il s’agit de la première livraison de la fonctionnalité, alors des améliorations (et pas des moindres) sont déjà dans les fourneaux :

  • plusieurs vues kanban par projet ;
  • une vue au niveau d’un groupe ;
  • un bouton pour voir ou cacher les tickets fermés ;
  • un bouton pour créer un ticket depuis cette vue ;
  • trier les tickets dans une colonne ;
  • chercher parmi toutes les listes ;
  • ou encore possibilité d’enlever la colonne backlog.

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.

Cela est‐il suffisant pour remplacer votre Kanboard (MIT), Wekan (MIT), Taiga (AGPL), Trello (propriétaire) ?

Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante, à la grande différence près que leur tableau ne se base pas sur les tickets.

Résoudre les conflits de fusion depuis GitLab

Peut‐être pas pour les gros conflits, mais enfin :

Commander GitLab depuis les commentaires (slash-commandes)

Inspirés par les tchats, Slack ou autres, ils ont ajouté leur version de commandes qui permettent de commander GitLab en écrivant une commande (qui commence par une oblique — slash — /) dans un champ texte, au lieu de faire ces actions à la souris.

Dans la capture suivante, l’utilisateur crée un ticket et spécifie les étiquettes et la version de publication (milestone) avec ces commandes (et l’auto‐complétion) :
slash commands

Liste des commandes :
http://docs.gitlab.com/ce/user/project/slash_commands.html

Intégration de l’EDI en ligne Koding

Nous voilà avec la possibilité de coder dans son environnement de développement intégré en ligne avec Koding.

Koding IDE

Il nous permettrait même d’utiliser notre éditeur favori (à l’heure où j’écris ces lignes, cela n’a pas été déployé sur gitlab.com).

Vidéo de présentation : 
https://www.youtube.com/watch?v=3wei5yv_Ye8

Résoudre les discussions en cours dans les demandes d’intégration

Lorsque l’on propose une demande d’intégration — merge request —, on peut discuter dans le diff du code, ligne par ligne. Cela peut être difficile à suivre, alors il est maintenant possible de marquer une discussion comme résolue.

Par conséquent, un bouton permet de passer d’une discussion non résolue à une autre.

Graphes pour visualiser son intégration continue

GitLab fournit clef en main une solution de CI (Intégration Continue). Une configuration pouvant devenir assez complexe, il est maintenant possible de la visualiser sous forme de graphe :

L’éditeur de code intégré permet de plier des parties de code

Il fait du repli de code (code folding) et améliore sa coloration syntaxique :

Badge de couverture de code

GitLab peut maintenant générer un badge qui montre le pourcentage de couverture de test du code :

Pour plus d’informations, voir la documentation.

Mattermost 3.3

GitLab est livré avec Mattermost 3.3, une alternative libre à Slack.

Et plus…

Vous pouvez tout lire dans les notes de version !

  • # Kanboard ou kanban?

    Posté par . Évalué à 6.

    Hello,
    je suis heureux de voir apparaitre cette vue, qui me semble très utile.

    Mais j'ai une remarque sur la forme, j'ai toujours eu l'impression qu'on parlait plutôt de vue kanban. Cela me perturbe d'autant plus que je suis utisateur de Kanboard et que j'ai tendance à associer ce terme spécifiquement à ce logiciel.

    A+

  • # Config recommandée

    Posté par . Évalué à 3.

    Des gens auraient testé la community avec du hardware moins costaud que ce qui est préconisé ? Je me vois difficilement mobiliser 2 Go de RAM pour un serveur git avec quelques services en plus pour 5 utilisateurs. Ils ont l'air de vivement déconseiller avec 1 Go de ram (ce qui me paraît déjà énorme, soit dit en passant).
    En attendant, j'utilise Gitbucket qui fait l'affaire, tourne pour quasi rien en ressources et bientôt un Kanboard dédié, en attendant de trouver des softs léger pour les autres features.

    • [^] # Re: Config recommandée

      Posté par (page perso) . Évalué à 2.

      Bah !? Tu veux pas utiliser 2 GiB de RAM et tu lances du java…

    • [^] # Re: Config recommandée

      Posté par (page perso) . Évalué à 2.

      un serveur git avec quelques services en plus

      C'est un peu plus que ca, non ?
      Et d'ailleurs, avec ou sans mattermost ?

    • [^] # Re: Config recommandée

      Posté par . Évalué à 8.

      Une alternative légère qui pourrait t'intéresser : gogs. Egalement open-source, elle est développé en go. Par contre, cette alternative ne propose pas autant de fonctionnalité que gitlab

      • [^] # Re: Config recommandée

        Posté par . Évalué à 1.

        Vu que je ne souhaite ni utiliser un LDAP, ni des utilisateurs Linux, je l'ai volontairement mis de côté. Monter un LDAP pour 5 utilisateurs, je trouve que c'est de l'overkill et je ne suis pas fan d'utiliser du PAM pour des logins applicatifs. Mais ça reste moins pire que d'autres, en fouinant j'ai vu un serveur git+web qui stockait les mots de passe en MD5, en 2016… Hélas j'ai oublié le nom de cette abomination.

        En tous cas, merci.

    • [^] # Re: Config recommandée

      Posté par . Évalué à 2.

      La solution la plus simple reste la solution mutualisée: gitlab.com: c'est gratuit, c'est pas ta ram, c'est toujours à jour, et t'as les fonctions payantes pour rien.
      Mais ton code est chez eux, donc tu vas pas pouvoir y mettre du soft secret défense.

  • # Réaction de Github

    Posté par . Évalué à 2.

    Github a été titillé par la concurrence, et a sorti en réaction au progrès de Gitlab un "nouvel univers".
    Il semble encore avoir une longueur d'avance, pas forcément technique mais communautaire. La force de github reste sans doute son aspect "réseau social", et Github tente d'attirer le chaland de multiples façons.
    Mais avec git (peut-être encore plus qu'avec d'autres technologies), le changement de plate-forme peut avoir lieu encore plus vite…

    • [^] # Re: Réaction de Github

      Posté par . É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: Réaction de Github

        Posté par . Évalué à 8.

        Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?

        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.

        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 ?

        demande à framasky qui a implémenté en version libre les pages statiques jusqu'alors dispos uniquement dans la version entreprise : cf. journal

        Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence.

        Je ne comprends pas ce qui te fait dire cela.

        • [^] # Re: Réaction de Github

          Posté par . Évalué à -3.

          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 ?

          Bref, je maintiens: open-source washing

          • [^] # Re: Réaction de Github

            Posté par (page perso) . Évalué à 6.

            Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …

            Tu crois mal : on l'utilise sur Framagit (car au départ notre gitlab était pour un usage interne). C'est l'utilisation de plusieurs LDAP qui est proprio.

            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

            En fait, si, tu peux avoir les sources de la version proprio : https://gitlab.com/gitlab-org/gitlab-ee :-)

            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 ?

            Oulà, pour ça, faudrait qu'on diverge du core… et c'est vraiment pas notre volonté : on aurait bien du mal à suivre l'upstream pour intégrer les nouvelles fonctionnalités tellement ça va vite.

            Comme Framasoft n'est pas une association de codeurs, on va plutôt encourager à contribuer upstream ou à faire un fork, mais on ne s'en occupera pas (et il faudrait vraiment qu'il y ait une truc de la mort qui tue pour qu'on passe au fork).

            It's a fez. I wear a fez now. Fezes are cool !

            • [^] # Re: Réaction de Github

              Posté par . Évalué à 0.

              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

              En fait, si, tu peux avoir les sources de la version proprio

              Je crois qu'il parlait du modèle de github. Son argument étant tant que gitlab n'a pas de communauté d'utilisateurs-développeurs forte, le fait qu'il soit libre ne le différencie pas vraiment de github. Par ce qu'il serait stupide pour une organisation d'investir dans de la RD pour au final se retrouver à maintenir son propre fork. Vous semblez confirmer ce point de vue, au niveau de votre organisation.

              On peut se demander aussi si ce constat est du à un manque de la demande ou à une à une offre volontairement bridée. En d'autres mots, est-ce que les clients "pros" demandent simplement une solution clefs-en-main sans réel besoin d'une solution complètement customisable; ce que pourrait être gitlab si il y avait un processus de développement communautaire non pipé (note: interprétation de "je conserve un avantage commercial sur toi"; personnellement je n'ai pas d'opinion éclairée sur ce sujet: j'évite l'un comme l'autre ;-) ).

          • [^] # Re: Réaction de Github

            Posté par (page perso) . Évalué à 3.

            je conserve un avantage commercial sur toi. (…) Bref, je maintiens: open-source washing

            Dit moi juste : à part garder le nom dans les sources, quel droit ont-ils de plus que toi sur le code libre qui t'empècherait de concurrencer leur version entreprise? J'en vois aucun (licence MIT), le problème est seulement tes compétences. de quel avantage commercial parles-tu donc?

            bref, je maintiens : tu fais du bashing gratuit; c'est franchement malsain.

            • [^] # Re: Réaction de Github

              Posté par . Évalué à 4.

              bref, je maintiens : tu fais du bashing gratuit; c'est franchement malsain.

              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 . Évalué à -2. Dernière modification le 22/09/16 à 11:15.

              N'empêche qu'il y a effectivement deux versions : CE qui est libre et EE qui n'est pas libre, et que la version EE contient des fonctionnalités en code privateur.

              Et quand on regarde l'histoire de GitLab, ce n'est pas rassurant du tout de constater qu'ils vont dans le mauvais sens : à l'origine, c'était 100 % libre et petit à petit de moins en moins. Quelle confiance leur accorder pour l'avenir ?

              Et quand on lit ça :

              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.

              Comment ne pas se dire qu'ils sont en incohérence avec les valeurs du libre ?

              De plus, si tu connais leur annonces officielles, tu t'aperçois que cette news LinuxFr est faite d'énormes copier/coller venant de GitLab, comme par exemple : https://about.gitlab.com/2016/08/22/announcing-the-gitlab-issue-board/

              On peut légitimement se poser la question de l'intérêt d'une news qui reprend juste la pub officielle.

              Donc oui, la question du open-source washing se pose vraiment.

              • [^] # Re: Réaction de Github

                Posté par (page perso) . Évalué à -1.

                code privateur

                Je t'invite à relire le commentaire auquel tu réponds.
                Et d'arrêter d'utiliser ce mot à la con (désolé pas d'autre mot) car le code en question ne te prive d'absolument rien du tout (tu peux faire exactement la même chose, même plus, quand tu as ce code que quand tu l'as pas).

                ce n'est pas rassurant du tout de constater qu'ils vont dans le mauvais sens : à l'origine, c'était 100 % libre et petit à petit de moins en moins.

                Et 100% de ce qui était avant libre est toujours libre.
                Tu dis qu'avoir 100 libre + 10 pas libre est "dans le mauvais sens" par rapport à 10 libre. Excuse-moi, moi je vois "dans le bon sens" (on a 90 en plus pour le libre).

                Tu n'aimes pas l'ajout de code non libre alors que tu peux code toi-même la chose (en libre ou pas, GitLab ne te bloque aucune possibilité de les concurrencer dans leur même modèle), soit, mais appeler ça open-source washing de près ou de loin est juste de la bêtise d’intégriste (mais vu le mot que tu utilises pour du code non libre : ce n'est pas étonnant ces mots dès qu'il y a un peu de code non libre, le libre ne t’intéressant pas, cracher sur x t’intéressant bien plus).

                El Titi a eu l'honnêteté de reconnaitre son erreur (il s'est trompé dans la licence, en pensant à une licence qui fait que le libre n'est qu'un produit d'appel pour vendre le code libre en non libre, donc que la valeur est de passer le code libre en non libre, alors que GitLab vend du code en plus pas libre), lui (il n'avait pas utilisé le mot "privateur", ça doit aider aussi).

        • [^] # Re: Réaction de Github

          Posté par (page perso) . Évalué à 4. Dernière modification le 21/09/16 à 08:01.

          demande à framasky qui a implémenté en version libre les pages statiques jusqu'alors dispos uniquement dans la version entreprise : cf. journal

          Et je suis pas le premier à l'avoir fait (il y a qq'un d'autre qui avait fait un gl-pages, mais j'ai préféré coder un truc plus basique et plus simple).

          A priori, ça ne les dérange pas. Rien n'interdit d'ajouter des fonctionnalités via les webhooks ou d'utiliser l'intégration continue, bien au contraire. Et tant qu'on ne leur pique pas leur code proprio…

          It's a fez. I wear a fez now. Fezes are cool !

      • [^] # Re: Réaction de Github

        Posté par (page perso) . Évalué à 6.

        (Contribuez, on est des gentiiiiils et nous on garde le beurre), (…) Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.

        D'habitude j'irai dans ton sens, en disant que le libre sert de produit d'appel pour te vendre la version proprio que personne d'autre ne peut faire (j'adore les "gentils libristes" qui disent faire de la GPL "pour que le libre reste libre le proprio c'est mal" et qu'ils vendent une version proprio "pour faire vivre le libre promis", ils oublient qu'en pratique ils gardent le monopole sur cette possibilité comme par hasard celle qui fait du fric sur le projet)

        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)

        Ton attaque n'a donc pas lui d'être : GitLab joue le jeu et ne garde aucun droit que pour eux.

        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 ?

        Tant que tu ne pompes pas de code proprio (donc comme tout projet), aucun risque, c'est libre.

        Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !

        C'est complètement mensonger : la code libre et libre, et ils te laissent libres de faire comme eux comme business model.


        Sérieux, la je ne comprend pas ton attaque, le libre est respecté, le modèle méritocratie aussi, tout le monde est libre de la même chose, ici.
        On n'est absolument pas dans le modèle "GPL pour le libre et donc que moi qui peut vendre en poprio, le libre n'est qu'un produit d'appel pour te fourguer ce dont j'ai le monopole".

        Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence.

        Je n'ai pas hurlé la dessus mais sur une attaque contre le projet lui-même.
        Mais si tu veux jouer à ça : je ne vois pas le rapport, gitHub garde la partie proprio au chaud, et n'offre aucune version utilisable en libre. Donc GitLab propose quand même bien mieux que GitHub en terme de premier démarrage si tu veux entrer en compétition avec eux. gitHub fait le gentil mais fait bien attention à ce que tu ne puisses pas facilement les concurrencer, alros que GitLab fait le nécessaire pour que si ils sont mauvais, tu puisses concurrencer.

        Sérieusement, tu ne vois pas la différence entre gitHub et GitLab, entre les dual licence copyleft et dual licence copyfree?

        • [^] # Re: Réaction de Github

          Posté par . Évalué à 6. Dernière modification le 21/09/16 à 22:28.

          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.

    • [^] # Re: Réaction de Github

      Posté par (page perso) . Évalué à 3.

      Github a été titillé par la concurrence, et a sorti en réaction au progrès de Gitlab un "nouvel univers".

      C'est pas plutôt en réaction à https://github.com/dear-github/dear-github ?

      Un peu comme la dépêche qui dit "Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante", j'aimerais bien une source qui indique c'est en réaction. Certes côté timing c'est quasi en même temps, presque trop pour que ce soit une réaction justement.

      Maintenant ces remarques n'enlèvent pas le fait que c'est une bonne chose qu'il y ait de la concurrence, ça force toujours à aller un peu plus loin. Et gitlab garde une avance avec leur CI pour le moment.

      • [^] # Re: Réaction de Github

        Posté par (page perso) . Évalué à 4.

        C'est pas plutôt en réaction à https://github.com/dear-github/dear-github ?

        Pour certains, c'est surtout la mise en place du management chez github (qui avait auparavant une structure hiérarchique très plate) qui a permis ça. C'est plus probablement un mélange de tout ça et il est clair que la compétition avec Gitlab force Github à sortir de nouvelles fonctionnalités. Tant mieux.

  • # Kanban board

    Posté par . Évalué à 3. Dernière modification le 21/09/16 à 10:12.

    Pour l'instant, lorsqu'on ferme une "Issue" via un commit + merge request dans la branche principale, elle apparaît toujours dans les colonnes du kanban board au lieu d'être dans la colonne "Done".

    Ce comportement est en train d'être modifié. Un filtre va être rajouté pour pouvoir masquer par défaut les issues qui ont été marquées comme fermées dans les commits, et on pourra les afficher si on le souhaite, et un point rouge indiquera lesquelles ont été fermées. De cette façon, on conserve le même comportement qu'actuellement (ce qui permet de conserver l'information comme quoi l'issue n'est pas passée par les étapes intermédiaires pour arriver jusqu'à "Done") mais on ne pollue plus la vue avec des issues qui ne doivent plus être résolues.

    Le rapport de bug est ici et toujours ouvert, donc j'imagine que ce ne sera pas intégré d'ici demain : https://gitlab.com/gitlab-org/gitlab-ce/issues/21691

    Vivement le 22 octobre donc !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.