Pour aller plus loin et répondre en parallèle à votre commentaire plus haut sur le pourquoi du comment :
Nous avons fait le choix de ne supporter qu'un seul moteur de DB (en fait MariaDB est compatible mais en vrai on a jamais eu de retour en prod à grande échelle) pour simplifier les problématiques de déploiement. Faire du On Prem c'est très compliqué, même avec des choix franchement clivants (1 seule version de PHP, 1 seule version de MySQL, 2 versions du même OS) ça représente un coût significatif de maintenance (exemple on attend ardemment la mort de RHEL6 dans 20 jours pour enfin pouvoir mettre à jour mediawiki). Ce temps, nous préférons le consacrer à du fonctionnel pour l'utilisateur final.
Nous avons également fait le choix de le pas utiliser d'ORM. En premier lieu parce qu'un ORM pour 1 seul moteur de DB c'est un peu overkill et en plus car le modèle de données des trackers (l'équivalent de Jira chez atlassian) est extrêmement complexe et, de tout façon il aurait fallu faire du by pass et écrire les requêtes à la main.
Le gros avantage c'est que l'on a la maîtrise complète de bout en bout et on a des perfs sur lesquels on a pas à rougir. Ça me fait un peu marrer la limite à 2000 utilisateurs des instances Jira on Prem quand on à 45'000 utilisateurs sur certaines des nôtres avec juste une séparation web serveur et DB (pas de cluster ou quoique ce soit de monstrueux, et des serveurs "standards").
Il y a deux ans, j'avais fait une installation de test. Rien que la partie mise en place du docker tuleap a été une vrai galère. Ca m'a pris 2 jrs à configurer chercher des configs pour mon besoin sur le net.
L'image docker publique est + à des fins de démo/test, il n'est pas recommandé de l'utiliser en production. Il y a une image officielle de prod mais uniquement pour Tuleap Entreprise pour le moment.
Est-ce que la partie wiki de tuleap permet un export pdf ?
Comment sont gérés les pertes ? Ce qui ne peux pas être reproduit dans tuleap ?
Pour le moment nous nous sommes concentrés sur l'import des données.
Ce qui ne peut pas être importé est ignoré, principalement pour éviter d'avoir des commentaires remplis de texte imbitable (data en vrac). Par contre on est preneurs de propositions sur le sujet de la part d'experts Jira.
Toute migration d'un outil à un autre nécessite de repenser une partie du workflow que l'on utilise (il y a des choses que l'on fait parce que l'outil nous oblige à fonctionner d'une certain façon) donc notre ambition n'est pas de faire l'import fonctionnel le + fidèle mais surtout de garder le + de données possible.
la création de rapport (et de mon souvenir c'est siffisament chiant à faire pour ne pas trop vouloir y revenir)
A l'heure actuelle, seuls les rapports par défaut sont importés. Les rapports sont assez facile à construire côté Tuleap donc ça peut être un compromis acceptable. Cela dit, on manque d'exemples probants de rapports pour essayer de les importer.
création workflow avec tout ce qui va avec comme gestion des rôles et gestion de formulaires pour chaque étapes du workflow
On n'importe le status et ses valeurs historisées concernant le workflow, pas la configuration. Je ne suis même pas sur qu'on soit capable d'avoir toute la config su WF par les APIs.
l'utilisation de divers plugin
Pas de plugins pour le moment.
la possibilité de scripter pas mal de chose en groovy (par exemple pour ajouter un champ calculé qui pourra ensuite être pris en compte dans les workflow)
Pareil, pas d'import d'autre chose que les datas.
faire du dry-run, rollback ou une quelconque manière de revenir en arrière pour s'y retrouver ?
C'est un import sur la base des APIs de Jira donc vous pouvez faire autant d'essais que vous le souhaitez, détruire ensuite l'import et recommencer.
avoir un listing de tout ce qui n'est pas importé pour pouvoir le gérer d'une manière ou d'une autre ?
Je ne suis pas certain que ça soit réalisable car la construction actuelle c'est que l'on "décide" de ce que l'on va importer (ex les reports par défaut) et on cherche comment cette info est accessible via les APIs de Jira. Ce n'est pas comme si on avait un export complet (genre un dump XML de l'intégralité des issues) et que l'on dise "ce truc là ça va devenir ça, etc).
Pour que quelque chose soit importable il faut:
* que l'on sache que la fonctionnalité existe
* qu'elle soit représentée dans l'API REST
* que le jeu en vaille la chandelle :)
Pourriez vous préciser les calculs que vous avez fait pour le critère de cohérence écologique ?
Déjà que dans un écosystème de container, la projection budgétaire/économique est complexe à faire (combien de nodes dans mon cluster pour combien de container pour quelle charge), vous avez du encore + vous casser la tête pour mesurer l'empreinte écologique de la solution (notamment sur la justification de la HA pour 30 utilisateurs). Je suis curieux de comprendre la démarche.
Le module Tuleap Test Management® est-il dispo avec la version Community ?
Non, la partie gestion des tests est uniquement dans Tuleap Enterprise
Il y a une partie "gamification" indiquée sur le site. A l'usage et d'expérience, ce genre de module est plutôt nuisible à l'activité de test et climat de l'équipe. Est-il désactivable ?
Elle est désactivable si la partie "gestion temps réel" n'est pas configurée côté serveur Tuleap.
Par contre je suis curieux de votre retour d’expérience sur le côté nuisible de la chose. De notre côté, nous avons plutôt vu des bénéfices (notamment le fait de voir que l'on est pas seul dans l'adversité, que les choses avances, etc).
Je suis également passé sur le Tuleap du projet Tuleap en voulant voir si le module était actif et naviguer dedans. Sur la page du module de test du projet Tuleap lui-même, j'obtiens le message
Le miroir que vous avez mentionné contient des modules Community ainsi qu'une partie des modules Entreprise.
Certains modules Entreprise et Community sont développés dans des dépôts séparés (un repo par module). Les dépôts Community sont publiquement accessibles, les dépôts Enterprise sont accessibles uniquement aux clients.
Vous vous situez ou par rapport à Gitlab et ses pipelines de CI ?
A l'heure actuelle, la CI/CD avec Tuleap c'est via Jenkins.
Notre stratégie de fournir une intégration transparente entre les deux outils (identification, déclencheurs, remontés des infos, etc).
Le cœur de CI & CD reste du Jenkins sous la responsabilité des équipes de Dev. Mais les diverses intégrations (notamment la gestion de la délégation de l'auth) couplé à une approche JCasC permet d'en réduire considérablement la maintenance.
Un des points chiant de ces pipelines est de ne pas voir les tester en local et attendre parfois 25 min leur fin.
Pour ça la solution Jenkins c'est Jenkinsfile runner. C'est encore en beta mais ca devrait répondre à la plupart des cas d'usage (après si les pipelines dépendent des bcp de trucs externe ca ne fera pas de miracle non plus).
C'est un vrai choix que d'investir dans la qualité du design des interfaces. Le coût associé est assez élevé mine de rien (c'est très très loin de "juste une CSS et des couleurs kivonbien").
L'inconsistance de la librairie standard est tjrs relevée comme étant une grosse tare du langage, bien souvent par ceux qui ne pratiquent pas au quotidien (aucune idée de si c'est le cas ici). Je me permettais de signaler qu'avec un outilage adéquat, ce problème est quasi inexistant.
C'est d'autant plus intéressant que la réécriture de la lib std PHP n'interviendra heureusement jamais "juste" pour reordonner des paramètres.
Tout langage a ses défauts (et peut être même que PHP en a plus que les autres), là où ça devient plus intéressant c'est ce que l'écosystème met en place autour de ces défauts pour les gommer. Et justement, l'écosystème PHP depuis ces 5 à 7 dernières années est particulièrement bien foutu et bien fournit.
Dommage qu'il y ait encore beaucoup d'incohérences au niveau des noms des fonctions et de l'ordre des paramètres, c'est un héritage nécessaire pour la rétro compatibilité, mais lourd à porter.
En vrai avec un bon IDE ça se passe très très bien.
Un petit coup de Psalm par dessus et ça se passe encore mieux
Je comprends le problème est, comme je l'ais évoqué plus haut, la solution c'est un "truc" externe qui peut s’exécuter dans une sandbox.
En tant que fournisseur de service (plus uniquement le logiciel cette fois ci), je ne peux pas donner à mes clients un couteau qui n'est formé de d'une lame une lame, sans manche et avec un post-it dessus: "faisez gaffe, ça coupe". Par ce que je sais qu'ils vont se couper et je sais que je vais devoir leur porter assistance parce que ça fait partie du job (je peux t'inviter à venir consulter nos logs de demande de support pour confirmer cela).
Aujourd'hui, ce que tu souhaites faire est déjà mis en place chez nos clients (et probablement dans la communauté aussi) via les mécanismes de webhooks & triggers, ça fonctionne bien, c'est méga stable, ça n'impose aucune contrainte sur le langage à utiliser et ça ne compromet pas le serveur.
En pratique, se mettre dans le contexte du dev d'un plugin impose un cadre beaucoup plus formel. S'il s'agit d'un plugin qui a vocation à être intégré dans la distribution communautaire il devra suivre des phases de revue de code, devra avoir des tests, ne pas casser les tests existants, etc.
De ce que j'ai pu voir dans les autres outils qui proposent ce genre de Feature, même limité aux admins plateforme, la qualité de l'implémentation est généralement très en dessous des critères d'exigence d'un code "publique". Pour ne prendre qu'un exemple, il n'est généralement même pas possible d'écrire des tests pour les fameux fichiers ou scripts.
Alors les plugins peuvent être développés par n'importe qui donc ce n'est pas le problème.
Par contre, fondamentalement on retombe sur le même problème de base: la sécurité du code de ces fameux fichiers uploadés + la maintenance des dits fichiers/scripts à la mise à jour (voire, pire, la prise en charge de plusieurs versions en parallèle).
Il ne s'agit pas de l'un ou de l'autre mais de l'un ET de autre. C'est le principe même de l'authentification multifacteur: quelque chose que tu sais (mot de passe, PIN) + quelque chose que tu as (token physique, code sur mobile, etc).
Le SMS est obsolète comme 2nd facteur depuis bien longtemps, c'est donc sage que les banques l'abandonne. Par contre il aurait été judicieux de proposer de systèmes standards d'OTP sans que chaque banque impose son app dont on peut légitimement questionner la robustesse.
J'aurais bien aimé utiliser ma YubiKey pour valider mes achats / virements. C'est assez dingue au final de se dire qu'on peut avoir un système plus secure pour mettre un commentaire sur GitHub que pour accéder à sa banque…
Ah, si tu veux passer par un plugin, c'est tout à fait faisable puisque la mécanique est déjà présente et il y a une belle collection déjà disponibles.
Cela dit, ca reste plutôt coûteux (en temps ou en argent) comme approche car le dev d'un plugin doit être un tant soit peu générique pour qu'il ait un sens (c'est à dire pour couvrir plus que le cas d'une seule personne sur un serveur).
Jenkins est un serveur de build, il permet de déclencher des jobs. Que ces jobs fassent du build de logiciel ou qu'ils exécutent des scripts pour automatiser de la création de "stuff" C'est la même chose. Et ça permet de bénéficier de l'écosystème de plugins Jenkins aussi (genre ne serait ce que pour avoir un truc propre pour gérer les creds)
Le point n°1 c'est la sécurité. On ne va pas laisser "n'importe qui" écrire son bout de code et l’exécuter "les yeux fermés".
On pourrait considérer que seuls quelques utilisateurs sélectionnés ont le droit de le faire mais se posent alors deux autres problèmes
- la dépendance aux admins centraux. Ce sont à eux d'écrire ou de revoir le code en question => ca ne sera pas fait et le point n°1 reste valable.
- la dépendance aux APIs internes de Tuleap. Tuleap bouge beaucoup et bouge vite, il n'y a aucune garantie de compatibilité sur les APIs internes. Le coût de mise à jour serait énorme pour garantir une upgrade "smooth".
La meilleure solution aujourd'hui est de se baser sur les mécanismes d'extension déjà présent (post-action "jenkins" du workflow ou webhooks) et d'avoir une implémentation indépendante qui utilise les APIs publiques (testées et stables) pour faire la logique particulière.
Peut être qu'a terme nous mettrons à disposition des éléments pour faciliter ces déploiements (genre github actions & co) mais c'est assez "lourd" à concevoir quand on doit prendre en compte le passage à l'échelle (autant j'imagine assez bien comment faire ça pour une petite instance à quelques dizaines d'utilisateurs, autant les instances avec 10k trackers et 45k personnes, la dépendance c'est une truc comme k8s ou OpenFaaS).
Je réponds ici même si je ne réponds pas précisément à ce commentaire en particulier parce que je suis impliqué la dedans => je suis le CTO d'Enalean qui est l'éditeur de Tuleap.
Pour faire simple, Tuleap est précisément dans le scope que tu vises même si tu ne pourras pas tout faire dans ta wish list (à partir de l'interface, avec l'API, c'est autre chose). Par exemple, créer des sous-tickets ça demande de taper l'API par contre définir des changements d'état de parents en fonction des statut des enfants, c'est built in.
En plus ça tombe bien, le workflow a été profondément refait depuis le début de l'année et 2 nouvelles post actions sont en cours de développement: la capacité à geler progressivement un "ticket" (rendre les champs en lecture seule en fonction de l'état) et la capacité à cacher/afficher des groupes de champs, toujours en fonction de l'état.
La grande force de Tuleap c'est précisément le point que tu relevais à propos de Jira: l'indépendance pour configurer des choses. Dans ton projet tu peux créer autant de trackers que tu le souhaite, les configurer en toute autonomie. Tu n'es pas obligé d'hériter des 120 champs du tracker de bug "groupe".
Alors c'est vrai que l'on a pas la force de frappe de communication la plus folle du marché mais on a pas à rougir de nos utilisateurs et on est plutôt fiers quand ils acceptent de témoigner des trucs de zinzin qu'ils font avec. Le plus gros déploiement connu par nous regroupe plus de 45'000 utilisateurs et à bientôt 2 milions d'artifacts (tickets) au compteur et sur une infra pas folle.
Ah et côté interfaces, on a un ou deux trucs sympa en préparation et on a pas chomé l'année dernière sur le sujet non plus ;)
L'entreprise pour laquelle vous travaillé finance peut être déjà des évolutions de Tuleap, rentrer en contact avec ces personnes peut être un bon moyen de faire avancer le sujet.
Et utiliser un captcha en logiciel libre, cela ne serait-il pas mieux ?
Je n'en connais pas d'efficace mais je suis preneur de retour d'expérience sur le sujet.
Parce que si pour utiliser tuleap.net il faut se soumettre à Google … l'intérêt de l'offre perd énormément de son intérêt :-/
A l'heure actuelle le captcha n'est présent qu'a l'enregistrement du compte ce qui n'arrive qu'une seule fois. Cette enregistrement peut être réalisé en mode incognito ce qui va considérablement limiter la quantité d'informations envoyées à google pour cette seule et unique requete faite auprès de ce service.
[^] # Re: À propos de la stack
Posté par vaceletm (site web personnel) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 6.
C'est dommage :)
Pour aller plus loin et répondre en parallèle à votre commentaire plus haut sur le pourquoi du comment :
Nous avons fait le choix de ne supporter qu'un seul moteur de DB (en fait MariaDB est compatible mais en vrai on a jamais eu de retour en prod à grande échelle) pour simplifier les problématiques de déploiement. Faire du On Prem c'est très compliqué, même avec des choix franchement clivants (1 seule version de PHP, 1 seule version de MySQL, 2 versions du même OS) ça représente un coût significatif de maintenance (exemple on attend ardemment la mort de RHEL6 dans 20 jours pour enfin pouvoir mettre à jour mediawiki). Ce temps, nous préférons le consacrer à du fonctionnel pour l'utilisateur final.
Nous avons également fait le choix de le pas utiliser d'ORM. En premier lieu parce qu'un ORM pour 1 seul moteur de DB c'est un peu overkill et en plus car le modèle de données des trackers (l'équivalent de Jira chez atlassian) est extrêmement complexe et, de tout façon il aurait fallu faire du by pass et écrire les requêtes à la main.
Le gros avantage c'est que l'on a la maîtrise complète de bout en bout et on a des perfs sur lesquels on a pas à rougir. Ça me fait un peu marrer la limite à 2000 utilisateurs des instances Jira on Prem quand on à 45'000 utilisateurs sur certaines des nôtres avec juste une séparation web serveur et DB (pas de cluster ou quoique ce soit de monstrueux, et des serveurs "standards").
[^] # Re: À propos de la stack
Posté par vaceletm (site web personnel) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 2.
PostgreSQL n'a jamais été supporté (et pas de support prévu).
[^] # Re: Tuleap en 2020 ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 2.
Pour les problèmes d'install, comme dit avant https://chat.tuleap.org
L'image docker publique est + à des fins de démo/test, il n'est pas recommandé de l'utiliser en production. Il y a une image officielle de prod mais uniquement pour Tuleap Entreprise pour le moment.
Oui
[^] # Re: À propos de la stack
Posté par vaceletm (site web personnel) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 2.
Yep, je confirme.
Oui oui, je confirme qu'on a bien compris. Tous les nouveaux devs sont en Vue.js et on migre progressivement les anciens devs AngularJS.
[^] # Re: Pertes
Posté par vaceletm (site web personnel) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 4.
Pour le moment nous nous sommes concentrés sur l'import des données.
Ce qui ne peut pas être importé est ignoré, principalement pour éviter d'avoir des commentaires remplis de texte imbitable (data en vrac). Par contre on est preneurs de propositions sur le sujet de la part d'experts Jira.
Toute migration d'un outil à un autre nécessite de repenser une partie du workflow que l'on utilise (il y a des choses que l'on fait parce que l'outil nous oblige à fonctionner d'une certain façon) donc notre ambition n'est pas de faire l'import fonctionnel le + fidèle mais surtout de garder le + de données possible.
A l'heure actuelle, seuls les rapports par défaut sont importés. Les rapports sont assez facile à construire côté Tuleap donc ça peut être un compromis acceptable. Cela dit, on manque d'exemples probants de rapports pour essayer de les importer.
On n'importe le status et ses valeurs historisées concernant le workflow, pas la configuration. Je ne suis même pas sur qu'on soit capable d'avoir toute la config su WF par les APIs.
Pas de plugins pour le moment.
Pareil, pas d'import d'autre chose que les datas.
C'est un import sur la base des APIs de Jira donc vous pouvez faire autant d'essais que vous le souhaitez, détruire ensuite l'import et recommencer.
Je ne suis pas certain que ça soit réalisable car la construction actuelle c'est que l'on "décide" de ce que l'on va importer (ex les reports par défaut) et on cherche comment cette info est accessible via les APIs de Jira. Ce n'est pas comme si on avait un export complet (genre un dump XML de l'intégralité des issues) et que l'on dise "ce truc là ça va devenir ça, etc).
Pour que quelque chose soit importable il faut:
* que l'on sache que la fonctionnalité existe
* qu'elle soit représentée dans l'API REST
* que le jeu en vaille la chandelle :)
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par vaceletm (site web personnel) . En réponse à la dépêche Liiibre, une solution complète pour vos projets collaboratifs. Évalué à 2.
Pourriez vous préciser les calculs que vous avez fait pour le critère de cohérence écologique ?
Déjà que dans un écosystème de container, la projection budgétaire/économique est complexe à faire (combien de nodes dans mon cluster pour combien de container pour quelle charge), vous avez du encore + vous casser la tête pour mesurer l'empreinte écologique de la solution (notamment sur la justification de la HA pour 30 utilisateurs). Je suis curieux de comprendre la démarche.
[^] # Re: Gamification™ et paramétrage Tuleap Test Management®
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 1.
Non, la partie gestion des tests est uniquement dans Tuleap Enterprise
Elle est désactivable si la partie "gestion temps réel" n'est pas configurée côté serveur Tuleap.
Par contre je suis curieux de votre retour d’expérience sur le côté nuisible de la chose. De notre côté, nous avons plutôt vu des bénéfices (notamment le fait de voir que l'on est pas seul dans l'adversité, que les choses avances, etc).
Oui, il s'agit d'un bug.
[^] # Re: Question sur les différentes versions disponible...
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 6.
Tout est GPLv2.
Le miroir que vous avez mentionné contient des modules Community ainsi qu'une partie des modules Entreprise.
Certains modules Entreprise et Community sont développés dans des dépôts séparés (un repo par module). Les dépôts Community sont publiquement accessibles, les dépôts Enterprise sont accessibles uniquement aux clients.
[^] # Re: Gitlab ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 3.
Merci :)
A l'heure actuelle, la CI/CD avec Tuleap c'est via Jenkins.
Notre stratégie de fournir une intégration transparente entre les deux outils (identification, déclencheurs, remontés des infos, etc).
Le cœur de CI & CD reste du Jenkins sous la responsabilité des équipes de Dev. Mais les diverses intégrations (notamment la gestion de la délégation de l'auth) couplé à une approche JCasC permet d'en réduire considérablement la maintenance.
C'est détaillé dans cet article en anglais https://blog.tuleap.org/seamless-integration-between-tuleap-and-jenkins/
Pour ça la solution Jenkins c'est Jenkinsfile runner. C'est encore en beta mais ca devrait répondre à la plupart des cas d'usage (après si les pipelines dépendent des bcp de trucs externe ca ne fera pas de miracle non plus).
[^] # Re: Très joli
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 5.
Merci, ça fait chaud au cœur \o/
C'est un vrai choix que d'investir dans la qualité du design des interfaces. Le coût associé est assez élevé mine de rien (c'est très très loin de "juste une CSS et des couleurs kivonbien").
[^] # Re: package Emacs
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 1. Dernière modification le 24 septembre 2020 à 13:11.
Pas à ma connaissance.
[^] # Re: Question sur les différentes versions disponible...
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 3.
Les sources d'une partie des modules Entreprise sont accessibles sur ce miroir.
Les autres modules Entreprise, libres également, sont dans des dépôts à part, uniquement accessibles aux clients.
[^] # Re: Rapporter un bug
Posté par vaceletm (site web personnel) . En réponse à la dépêche Gestion des plans de tests, intégration continue, nouvelle UI : version majeure Tuleap 12. Évalué à 4.
Merci pour le signalement, c'est enregistré et un patch est en revu !
[^] # Re: Phôte de phrape
Posté par vaceletm (site web personnel) . En réponse à la dépêche PHP 7.4. Évalué à 4.
Bien sûr, je ne dis pas le contraire.
L'inconsistance de la librairie standard est tjrs relevée comme étant une grosse tare du langage, bien souvent par ceux qui ne pratiquent pas au quotidien (aucune idée de si c'est le cas ici). Je me permettais de signaler qu'avec un outilage adéquat, ce problème est quasi inexistant.
C'est d'autant plus intéressant que la réécriture de la lib std PHP n'interviendra heureusement jamais "juste" pour reordonner des paramètres.
Tout langage a ses défauts (et peut être même que PHP en a plus que les autres), là où ça devient plus intéressant c'est ce que l'écosystème met en place autour de ces défauts pour les gommer. Et justement, l'écosystème PHP depuis ces 5 à 7 dernières années est particulièrement bien foutu et bien fournit.
Après c'est vrai que ça fait bien de basher PHP.
[^] # Re: Phôte de phrape
Posté par vaceletm (site web personnel) . En réponse à la dépêche PHP 7.4. Évalué à 1.
En vrai avec un bon IDE ça se passe très très bien.
Un petit coup de Psalm par dessus et ça se passe encore mieux
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 1.
Voici un exemple sur notre blog https://blog.tuleap.org/how-connect-tuleap-tracker-jenkins-job
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 1.
Je comprends le problème est, comme je l'ais évoqué plus haut, la solution c'est un "truc" externe qui peut s’exécuter dans une sandbox.
En tant que fournisseur de service (plus uniquement le logiciel cette fois ci), je ne peux pas donner à mes clients un couteau qui n'est formé de d'une lame une lame, sans manche et avec un post-it dessus: "faisez gaffe, ça coupe". Par ce que je sais qu'ils vont se couper et je sais que je vais devoir leur porter assistance parce que ça fait partie du job (je peux t'inviter à venir consulter nos logs de demande de support pour confirmer cela).
Aujourd'hui, ce que tu souhaites faire est déjà mis en place chez nos clients (et probablement dans la communauté aussi) via les mécanismes de webhooks & triggers, ça fonctionne bien, c'est méga stable, ça n'impose aucune contrainte sur le langage à utiliser et ça ne compromet pas le serveur.
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 1.
En théorie oui c'est la même chose.
En pratique, se mettre dans le contexte du dev d'un plugin impose un cadre beaucoup plus formel. S'il s'agit d'un plugin qui a vocation à être intégré dans la distribution communautaire il devra suivre des phases de revue de code, devra avoir des tests, ne pas casser les tests existants, etc.
De ce que j'ai pu voir dans les autres outils qui proposent ce genre de Feature, même limité aux admins plateforme, la qualité de l'implémentation est généralement très en dessous des critères d'exigence d'un code "publique". Pour ne prendre qu'un exemple, il n'est généralement même pas possible d'écrire des tests pour les fameux fichiers ou scripts.
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 1.
Alors les plugins peuvent être développés par n'importe qui donc ce n'est pas le problème.
Par contre, fondamentalement on retombe sur le même problème de base: la sécurité du code de ces fameux fichiers uploadés + la maintenance des dits fichiers/scripts à la mise à jour (voire, pire, la prise en charge de plusieurs versions en parallèle).
[^] # Re: double authentification ?
Posté par vaceletm (site web personnel) . En réponse au journal Lettre ouverte à La Banque Postale. Évalué à 10.
Il ne s'agit pas de l'un ou de l'autre mais de l'un ET de autre. C'est le principe même de l'authentification multifacteur: quelque chose que tu sais (mot de passe, PIN) + quelque chose que tu as (token physique, code sur mobile, etc).
Le SMS est obsolète comme 2nd facteur depuis bien longtemps, c'est donc sage que les banques l'abandonne. Par contre il aurait été judicieux de proposer de systèmes standards d'OTP sans que chaque banque impose son app dont on peut légitimement questionner la robustesse.
J'aurais bien aimé utiliser ma YubiKey pour valider mes achats / virements. C'est assez dingue au final de se dire qu'on peut avoir un système plus secure pour mettre un commentaire sur GitHub que pour accéder à sa banque…
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 2.
Ah, si tu veux passer par un plugin, c'est tout à fait faisable puisque la mécanique est déjà présente et il y a une belle collection déjà disponibles.
Cela dit, ca reste plutôt coûteux (en temps ou en argent) comme approche car le dev d'un plugin doit être un tant soit peu générique pour qu'il ait un sens (c'est à dire pour couvrir plus que le cas d'une seule personne sur un serveur).
Jenkins est un serveur de build, il permet de déclencher des jobs. Que ces jobs fassent du build de logiciel ou qu'ils exécutent des scripts pour automatiser de la création de "stuff" C'est la même chose. Et ça permet de bénéficier de l'écosystème de plugins Jenkins aussi (genre ne serait ce que pour avoir un truc propre pour gérer les creds)
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 2.
Le point n°1 c'est la sécurité. On ne va pas laisser "n'importe qui" écrire son bout de code et l’exécuter "les yeux fermés".
On pourrait considérer que seuls quelques utilisateurs sélectionnés ont le droit de le faire mais se posent alors deux autres problèmes
- la dépendance aux admins centraux. Ce sont à eux d'écrire ou de revoir le code en question => ca ne sera pas fait et le point n°1 reste valable.
- la dépendance aux APIs internes de Tuleap. Tuleap bouge beaucoup et bouge vite, il n'y a aucune garantie de compatibilité sur les APIs internes. Le coût de mise à jour serait énorme pour garantir une upgrade "smooth".
La meilleure solution aujourd'hui est de se baser sur les mécanismes d'extension déjà présent (post-action "jenkins" du workflow ou webhooks) et d'avoir une implémentation indépendante qui utilise les APIs publiques (testées et stables) pour faire la logique particulière.
Peut être qu'a terme nous mettrons à disposition des éléments pour faciliter ces déploiements (genre github actions & co) mais c'est assez "lourd" à concevoir quand on doit prendre en compte le passage à l'échelle (autant j'imagine assez bien comment faire ça pour une petite instance à quelques dizaines d'utilisateurs, autant les instances avec 10k trackers et 45k personnes, la dépendance c'est une truc comme k8s ou OpenFaaS).
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . En réponse au journal Gestion des tickets/workflows. Évalué à 6.
Je réponds ici même si je ne réponds pas précisément à ce commentaire en particulier parce que je suis impliqué la dedans => je suis le CTO d'Enalean qui est l'éditeur de Tuleap.
Pour faire simple, Tuleap est précisément dans le scope que tu vises même si tu ne pourras pas tout faire dans ta wish list (à partir de l'interface, avec l'API, c'est autre chose). Par exemple, créer des sous-tickets ça demande de taper l'API par contre définir des changements d'état de parents en fonction des statut des enfants, c'est built in.
En plus ça tombe bien, le workflow a été profondément refait depuis le début de l'année et 2 nouvelles post actions sont en cours de développement: la capacité à geler progressivement un "ticket" (rendre les champs en lecture seule en fonction de l'état) et la capacité à cacher/afficher des groupes de champs, toujours en fonction de l'état.
La grande force de Tuleap c'est précisément le point que tu relevais à propos de Jira: l'indépendance pour configurer des choses. Dans ton projet tu peux créer autant de trackers que tu le souhaite, les configurer en toute autonomie. Tu n'es pas obligé d'hériter des 120 champs du tracker de bug "groupe".
Alors c'est vrai que l'on a pas la force de frappe de communication la plus folle du marché mais on a pas à rougir de nos utilisateurs et on est plutôt fiers quand ils acceptent de témoigner des trucs de zinzin qu'ils font avec. Le plus gros déploiement connu par nous regroupe plus de 45'000 utilisateurs et à bientôt 2 milions d'artifacts (tickets) au compteur et sur une infra pas folle.
Ah et côté interfaces, on a un ou deux trucs sympa en préparation et on a pas chomé l'année dernière sur le sujet non plus ;)
[^] # Re: Gestion de la signature des commits git ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 1.
J'oubliais.
L'entreprise pour laquelle vous travaillé finance peut être déjà des évolutions de Tuleap, rentrer en contact avec ces personnes peut être un bon moyen de faire avancer le sujet.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 5.
Je n'en connais pas d'efficace mais je suis preneur de retour d'expérience sur le sujet.
A l'heure actuelle le captcha n'est présent qu'a l'enregistrement du compte ce qui n'arrive qu'une seule fois. Cette enregistrement peut être réalisé en mode incognito ce qui va considérablement limiter la quantité d'informations envoyées à google pour cette seule et unique requete faite auprès de ce service.