[SF5] Plan de migration about lairdubois HOT 25 OPEN

Ok je te contacte ce week-end, la fin de semaine est chargée ! On pourra se faire une visio !

from lairdubois.

@bbeaulant la réécriture complète serait trop chronophage pour tout le monde et personnellement je n'aurais pas le temps nécessaire à y consacrer.

Maintenant je maintiens ce que je disais il y a quelques mois, on peut tout à fait prendre l'existant et le porter sur les nouvelles versions moyennant quelques adaptations mais on est pas à l'abris de surprises sur ce genre de projet :|

D'ici fin de semaine j'espère pouvoir pousser une première version avec la partie backend adaptée.

Coté conf mini requis je peux déjà dire qu'on sera sur du php 7.4 mini et un ES 7
Pour le reste on verra au fur et à mesure 😄

from lairdubois.

Pas de soucis @lobodol, toutes les contributions sont des pierres à empiler pour monter la cathédrale :)

from lairdubois.

@lobodol j'ai fait quelques retours sur ta PR #68 😉

@bbeaulant Pour ce qui est de la branche migration-sf5, j'ai réussi à tout installer. J'ai fait la PR #92 avec des explications 😉

Mais j'ai des soucis bloquants pour la suite :

• Il n'y a pas (plus?) de fixtures, donc la bdd est clairement vide au démarrage.
• Au lancement de l'appli web sur mon navigateur, j'ai cette erreur
  
• J'ai une erreur lorsque je tente d'alimenter FOSElastica:
  

En tout cas, je suis ravi de voir qu'Assetic est parti, et que FOSUser aussi ! 👍

from lairdubois.

salut @Pierstoval !
Un peu de sang frais va faire du bien car je vais avoir moins de temps maintenant !
Pour ton problème il faut que tu initialises correctement elasticsearch :
symfony console fos:elastica:reset-templates
symfony console fos:elastica:reset
symfony console fos:elastica:populate
Le deuxième est pas obligatoire il me semble mais dans le doute ça mange pas de pain

Et pour les fixtures non y a pas :|

from lairdubois.

Une chose que je pense être indispensable, à la fois pour plus facilement appréhender le projet et pour le rendre maintenable à long terme, ce serait de créer des tests fonctionnels, même des smoke tests.

Pour ça, il faut un minimum de fixtures, genre des comptes utilisateurs avec des permissions classiques (un admin, un utilisateur lambda, etc.), et peut-être des données indispensables s'il y en a.

En gros, tout ce qu'il est nécessaire d'avoir dans la BDD pour que le projet fonctionne.

Une fois qu'on a ça, je peux m'atteler à la tâche de réaliser un max de smoke tests.
Un exemple tout simple est de créer toute une batterie de tests sur toutes les routes en GET, ça peut se faire très rapidement.
Ensuite pour toutes les routes en POST (formulaires, etc.), Symfony est assez bien fourni pour qu'on puisse en écrire facilement aussi :)

from lairdubois.

Whaou ! Merci @gaelb80 pour la proposition !

Je crois que c'est la propal que j'espère secrètement depuis que la v4 est sortie ... hihi.
Je plussois que ce chantier doit être lancé. C'est indispensable à la pérennité du projet et à son évolution.

Ca risque de ne pas se faire sans accroc, par contre. Je crois avoir usé et abusé d'outils/bundles externes et retrouver un équilibre dans tout ça demandera pas mal d'heures de travail à mon avis. Mais je suis soulagé d'apprendre que tu as déjà pratiqué ce genre de migrations. Ca pourra éviter pas mal de temps perdu à chercher des problèmes communs.

Pour aller plus loin, je pense que ça serait bien de s'en causer de vive voix. Contacte moi en MP sur L'Air du Bois :)

from lairdubois.

Besoin d'un coup de main de la part d'un autre expert Symfony ? (je viens à peine de découvrir L'air du Bois, et le mot "Open Source" a titillé mes oreilles, et j'ai vu ce ticket sur Github, alors je m'incruste 😁)

Symfony 6 sort à la fin 2021 😉

from lairdubois.

Salut,

un peu d'aide ne serait pas de refus effectivement :)

j'avais mis le projet de côté faute de temps et pris par des projets pros ces derniers mois mais j'ai un petit creux entre deux projets donc je pensais m'y remettre la semaine prochaine donc ta proposition tombe à pic.
L'idée était de partir sur une 5.4 (elle sort le mois prochain) pour assurer quelques années de maintenance.

Il faut que je reprenne ce que j'avais déjà fait et intègre les dernières modifications de @bbeaulant pour faire une PR sur la branche sf5.
J'espère pouvoir la faire d'ici la fin de semaine et ensuite si tu veux on se calera pour voir comment s'organiser pour travailler ensemble.

Le plus gros chantier sera très certainement la gestion des assets sachant que contrairement à ce qui est marqué dans RM initiale pas de migration bootstrap dans un premier temps :)

On se tient au jus !

from lairdubois.

Salut à tous les deux,

Merci @Pierstoval de proposer ton aide 👍 !
J'ai grande envie de partager votre optimisme sur le fait que la migration puisse se faire sans trop d'encombres et sur un délais raisonnable.

La base PHP (hors bundle spécifiques) ne me semble pas du tout insurmontable. C'est vrai. Même si au final la structuration des projets SF a bien changé depuis Flex et donc avec pas mal de nouvelles logiques d'écriture.

Ce que je crains le plus, c'est d'une part les assets, mais surtout la "mise en page" CSS qui est totalement calquée sur le support de BS3. Les JS qui dépendent de jQuery à 200% et à côté de ça tous les petits détails spécifiques, jusqu'à ceux aux fond d'un formulaire. Qui fond qu'à mes yeux, il serait surement aussi efficace de tout réécrire sans chercher à migrer. Et voir plus efficace sur le long terme pour avoir un truc moins patchwork.

Dans les deux cas, ce n'est pas une chose qui peut se faire sans pouvoir y consacrer une dose énorme de temps.
Je pense qu'il faut être conscient de ça.

Après @gaelb80, je te sens super confiant à ce que ça puisse être fait donc, dans un sens, ça me rassure.
Mais sachons aussi viser juste pour que le travail puisse se mener à son terme.

from lairdubois.

Tant que les assets peuvent être bundlés normalement et que le frontend fonctionne, il n'y a pas d'obligation stricte de mettre ça à jour. Il n'y a pas de problèmes de sécurité critique qui soit absolument impossible à gérer, je pense 😉

from lairdubois.

Bon la migration a bien avancé cette semaine sur mon fork, on a un semblant de projet qui fonctionne :)
On est sur un step bloquant dont je n'ai pas eut le temps de m'occuper : la suppression de FOSUser

@Pierstoval est-ce que tu es motivé pour t'en occuper du coup ?

L'idée est de rapatrier la gestion des users dans le projet avec :

• Formulaire d'inscription
• Confirmation d'inscription par email
• Authentification
• mot de passe oublié

la partie renseignement profil existe déjà dans le projet donc à reprendre.

Tiens moi au jus si c'est envisageable ou pas !

from lairdubois.

Super, merci @gaelb80.

L'idée est de rapatrier la gestion des users dans le projet [...]

Attention tout de même que la class User ne manque pas de complexité. Elle est utilisée presque partout et permet aussi d'être déclinée en users "Personne" et users "Collectif". Mais bon globalement tout ça n'est pas à changer dans la classe actuelle User.

from lairdubois.

La suppression de FOSUser me plaît, pour l'avoir déjà fait sur d'autres projets ! 😁

Je suis au Forum PHP cette semaine, et indispo entre temps, mais à partir de la semaine prochaine je devrais avoir du temps !

from lairdubois.

Cool :)

from lairdubois.

Super, quand t'es dispo fais nous signe qu'on voit comment s'organiser !

from lairdubois.

Salut à tous,

Afin de pouvoir avancer sur le test de la migration entrepris par @gaelb80. Super boulot à toi au passage, merci !
Je me suis permis de migrer l'e code dans la branche https://github.com/lairdubois/lairdubois/tree/migration-sf5 sur le repository principal.

J'ai aussi :

• mis en place un env de dev avec Docker sur la base du travail de @lobodol. A perfectionner.
• écrit grossièrement le code pour que register, login, logout fonctionne. Ainsi, on peut créer des comptes, s'y connecter et tester plus en profondeur la migration.

Voilou, pour avancer conjointement, je vous propose donc de fonctionner via des PR sur cette branche. Qu'en pensez-vous ?

from lairdubois.

Salut à tous,

Afin de pouvoir avancer sur le test de la migration entrepris par @gaelb80. Super boulot à toi au passage, merci ! Je me suis permis de migrer l'e code dans la branche https://github.com/lairdubois/lairdubois/tree/migration-sf5 sur le repository principal.

J'ai aussi :

* mis en place un env de dev avec Docker sur la base du travail de @lobodol. A perfectionner.

* écrit grossièrement le code pour que register, login, logout fonctionne. Ainsi, on peut créer des comptes, s'y connecter et tester plus en profondeur la migration.

Voilou, pour avancer conjointement, je vous propose donc de fonctionner via des PR sur cette branche. Qu'en pensez-vous ?

Salut @bbeaulant , impec ! Dsl j'ai pas trop eu de temps dernièrement pour avancer sur la partie Docker (mon activité pro me prend bcp de temps). J'essaierai de m'y remettre bientôt. D'ailleurs je suis preneur de vos retours si vous en avez.
Bonne journée à tous !

from lairdubois.

Salut @Pierstoval ,

Oui, y a pas de fixture à l'heure actuelle, pke j'étais seul et que je travaillais avec un import de la bdd de prod quand il y avait besoin.
La tâche de maintenir des fixtures était dans ce contexte très superflu.

En l'état, la branche master est amenée à disparaitre. Il serait inutile de travailler dessus.

Après, à cette heure la branche migration n'est pas complètement opérationnelle non plus. La migration a interrogée pas mal de choses qui ne sont plus très clean dans la façon dont je l'avais fait. Et ça ne me va pas. Y a donc encore du taf pour 1. rendre toutes les fonctions opérationnelles 2. cleaner la structure pour que ça soit maintenable sur le long terme.

from lairdubois.

Salut @Pierstoval,

Je plussois ton enthousiasme et je reconnais que l'ajout de test unitaires serait un plus.
Après, mon expérience de dev m'a toujours laissé rétissant à ça :

• c'est un truc de plus à maintenir
• tout ne peut pas être tester
• les tests eux-mêmes sont à debugger ... encore du temps.

Tout ça pour dire que j'aime l'idée que l'on puisse mettre ça en place. Mais attention à la vision long terme du truc et des implications à maintenir les choses à jour pour d'autres dev.

Bref, comme tu le vois, l'idée me plait, mais je reste à convaincre par les faits positifs :)

from lairdubois.

En ce qui me concerne, je suis totalement pour, je ne conçois pas aujourd'hui de développer de "gros" projet sans tests unitaires.

Je répète souvent un truc aux personnes que je forme sur les TU : soit sympa avec ton toi du futur et écris des tests.
Parce que les tests servent aussi à comprendre comment fonctionne les choses.

Par contre, pour qu'ils soient utiles, ils doivent être rapides et simple à exécuter. Sinon personne ne les fera tourner et ils tomberont dans l'oubli.

En ce qui me concerne, je suis chaud pour ajouter des tests à l'occasion.

Il faudra qu'on parle sécurité aussi à un moment, j'ai identifié beaucoup de endpoint/webservice vulnérables. Peut-être dans une autre issue.

from lairdubois.

J'ai rien contre le TU dans le principe. Mais sachons juste ne pas être trop gourmand pour savoir facilement les tenir à jour.

Il faudra qu'on parle sécurité aussi à un moment, j'ai identifié beaucoup de endpoint/webservice vulnérables.

Wep, ouvre une autre issue. A voir aussi si c'est intéressant d'exposer ces retours en public. Sinon @lobodol, tu as reçu une invitation pour rejoindre le slack.

from lairdubois.

Les TU sont là pour tester la logique des classes.

Dans un premier temps, des tests fonctionnels avec le WebTestCase de Symfony me semblent à la fois plus simple/rapide à écrire ET utiles pour permettre de mettre à jour le backend sans impacter les tests fonctionnels (chose qui fait bien chier quand on refacto une archi entière et qu'il y a des tonnes de TU derrière à mettre à jour)

from lairdubois.

Pour les arguments :

• c'est un truc de plus à maintenir

Oui, mais ça veut dire moins de bugs en prod à long terme aussi, donc moins de debug, donc moins de temps passé sur le projet à essayer de corriger des trucs :)

• tout ne peut pas être tester

Non, et il est peu probable que tout soit testé sur un projet d'une telle ampleur, et c'est pas si grave

• les tests eux-mêmes sont à debugger ... encore du temps.

Debugguer des tests, c'est ... debugguer ton code, donc c'est le même genre que lorsque tu as un bug sur ta prod :)

from lairdubois.

Mais sachons juste ne pas être trop gourmand pour savoir facilement les tenir à jour.

Tout à fait d'accord. Soyons pragmatiques et avançons pas à pas. Et à mon avis, ça commence avec des tests unitaires simples (pas de tests fonctionnels) et on itère là-dessus.
Ce qui est primordial, c'est qu'il soit simple d'exécuter les tests.

A voir aussi si c'est intéressant d'exposer ces retours en public.

Je ne pense pas que ce soit une bonne idée de les exposer en publique pour l'instant. On pourra en discuter sur le slack.

from lairdubois.