Discussion :

[sekaijin]

Bonjour

Après une très longue absence dans le monde PHP, je reviens pour quelques questions sur symfony.

J'ai du mal avec l'organisation des dossiers
je suis habitué à avoir 3 grands espaces dans mon organisation
les outils (tout ce qui permet de créer modifier traiter le projet)
les sources (tout le code que le développeur doit manipuler)
les livrables (tout ce que le serveur doit recevoir pour pouvoir exécuter l'appli)

Après avoir fait un symfony new demo j'ai l'impression que tout est en vrac. Je me trompe probablement mais qu'est-ce qui fait partit du code source est doit aller dans SVN ou Git ? J'ai du mal à le voir. Qu'est qui est de l'outillage du poste du développeur ?
Et surtout qu'est-ce qui au final ira sur le serveur ?

Je pense qu'avec un peut de pratique cela va s'éclaircir. Je comprends pourquoi un collègue a écrit des scripts Python pour ne livrer que ce qui doit l'être. Par contre faute de mieux il met tout sur svn ce qui pose de sérieux Pb de travail en équipe.

J'ai par le passé utilisé PHPUnit et il suffisait d'ouvrir une URL pour avoir un beau rapport d'exécution des tests? C'était probablement la préhistoire mais c'était simple.
Là je n'ai pas trouvé comment faire.

De l'aide sur ce point serait la bien venue.

A+JYT

[dukoid]

bonjour,


c'est très simple, AppBundle va contenir tout ton code.

/src/AppBundle/...


par exemple le site est composé de 3 parties : gestion, stock, statistique

/entity/... donc les entités des 3 parties car il represente la base de donnée

/resource/controler/GestionControler
/resource/controler/StockControler
/resource/controler/StatistiqueControler

/resource/view/Gestion/.... // toutes les vues de gestion
/resource/view/Stock/....
/resource/view/Statistique/....

/service/Gestion/.... // le code métier . bonne pratique : les controleur font appels aux services pour executer du code métier (au lieu de laisser le code métier dans les controleurs)
/service/Stock/.... // c'est en quelque sortes tes outils
/service/Statistique/....

/test/Gestion/.... // les tests en general en utilisant un bundle externe PHPUnit
/Test/Stock/....
/Test/Statistique/....


tout est bien classé !


Tout le dossier est le livrable. aussi simple que ça.


ne doit pas faire partie de git, svn.. : les dossiers /cache, /log, /vendor et /web



je ne vois pas le rapport entre python et ce que tu évoques. python c'est un langage... rien de plus. comme PHP ou le langage C.
Symfony n'a rien à envier aux autres framework, ils disposent de tout ce qu'il faut pour être le meilleur dans sa catégorie (création de gros projets). le tout avec une fiabilité exemplaire...




tu peux trouver de bon tutos sur internet, comme celui là :
https://blog.netapsys.fr/phpunit-et-...mise-en-place/


Google est ton ami !

[sekaijin]

Merci pour la réponse mais ne voit pas pourquoi les tests font partit du livrable

pour moi bin ne doit pas être livré pas plus que test.
quand je dis que tout me semble en vrac ce n'est pas que tout est dans le même dossier mais
que les phase ne me semble pas clairement identifié.

pour moi un développeur qui récupère le projet installe les outils
mets les sources dans sont workspace
exécute la command de build
et se retrouve avec un dossier qui contient les fichiers de travail
et un dossier ou un zip qui contient le livrable.

là j'ai x dossiers au même niveau certain contiennent des sources d'autres des fichier de travail d'autre des fichier générés. d'autre un mélange des deux

Pour faire la livraison il me faut extraire de tout ça ce qui est est nécessaire à l'exécution et ne surtout pas mettre les fichier de travail les outils et les fichiers source qui ne servent pas à l'exécution mais au outils de dev.

Le python dont je parle est simplement un script qui lorsqu'il est exécuté va justement piocher dans toutes cette hiérarchie les fichiers à livrer.

Mise à jour:
Après une journée à chercher des tutos et des docs je dois dire que je n'ai pas avancer
1000 tutos => 1000 fois comment installer symfony et créer un projet sur le poste développeur , 0 pour extraire ce qui est à déployer, 0 comment exécuter les tests.
Pas un mot sur la notion de livrable, pas une fois une description claire de quelques fichier prendre et quel fichier laisser. sauf ce qui est évidant "ne pas instaler en prod les fichiers de log"

Je suis un vieux routard, je le conçois mais j'espère que le dossier de dev n'est pas posé tel-quel en prod car là ce serait un vrai merdier pour les exploitants.

Je suis bien tombé sur un article qui avec composer propose de créer un PHAR. pour quoi pas ! sur la doc ça parait une bonne solution, mais là rien ne fonctionne
les commandes composer comme update ou install pas de pb mais les autre comme build sont inconnues de composer.

A+JYT

[dukoid]

e les tests sont présent en prod tout simplement pour tester en prod que tout va bien après le déploiement !

le dossier /bin est présent car cela permet de lancer des commandes en PROD !
comme commande on peut vouloir vider le cache, debuguer certaines choses en cas de problème.... et pleins d'autres choses

normalement on ne doit pas transférer en PROD le dossier /vendor.
celui ci doit être généré avec un composer install en PROD.

là j'ai x dossiers au même niveau certain contiennent des sources d'autres des fichier de travail d'autre des fichier générés. d'autre un mélange des deux

cad ? exemples ? qu'appelles tu fichier générés, outils ?


les fichiers sources sont dans /src (tout le code développé se trouve dans ce dossier)
les bundles utilisés par tes sources sont dans /vendor (et ne doivent pas être touché, c'est pour cela qu'ils sont à part)

je trouve que c'est très bien classé, non ? les 2 ne sont pas mélangés, c'est clair, pratique....



Pour la livraison on peut le faire manuellement avec filezila ou utiliser des outils de déploiement !

1000 tutos => 1000 fois comment installer symfony et créer un projet sur le poste développeur , 0 pour extraire ce qui est à déployer, 0 comment exécuter les tests.
Pas un mot sur la notion de livrable, pas une fois une description claire de quelques fichier prendre et quel fichier laisser. sauf ce qui est évidant "ne pas installer en prod les fichiers de log"

mais sache que tu peux transférer tout ton dossier(meme le cache et log) en PROD ça fonctionnera et n'aura aucune incidence sur la sécurité. (car tout ce qui est DEV n'est pas exécutable en PROD)
c'est pourtant simple !

pour être pointilleux et faire les choses classes, je l'ai expliqué dans ma réponse précedente comment faire (ce qu'il fallait mettre en prod ou pas).

Je suis un vieux routard, je le conçois mais j'espère que le dossier de dev n'est pas posé tel-quel en prod car là ce serait un vrai merdier pour les exploitants.

le /dossier dev ? il n'y en a pas. mais des fichier en .dev oui. ces fichier sont protégés et ne peuvent être exécuté en PROD




Symfony existe depuis 10 ans, si les choses sont faites ainsi cela a été mûrement réfléchi d'année en année.
de nombreuses entreprises utilisent Symfony, si celui ci n'était pas pratique (car c'est son but) je ne croirai pas qu'il est le succès qu'on lui connait aujourd'hui

[sekaijin]

des tests unitaires en prod...
ce n'est pas ce que j'appellerais propre.

les fichiers less servent a créer les fichiers css et n'ont rien a faire en prod.

que ça marche je n'en doute pas sinon ça fait longtemps que ça n'existerait plus.

je comprends que certains de mes développeurs aient créer un script python pour livrer.

lorsque j'installe wordpress ou phpmyadmin ou je ne sais quelle autre appli je n'ai pas tout les fichiers de développeurs.

je comprends mieux pourquoi les fichiers eclipse ou netbean se retrouvent en prod.

je conclus que si je veux déployer proprement il va me falloir faire le tri moi même et que l'outil ne m'aidera pas.

merci tout de même ça éclairci bien des choses.

A+
PS: cela explique pourquoi la doc indique quelques outils externes à utiliser pour déployer
https://symfony.com/doc/current/depl...ployment-tasks

[dukoid]

il y a Capifony pour déployer des projets de façon automatique.

[sekaijin]

...
que ça marche je n'en doute pas sinon ça fait longtemps que ça n'existerait plus.
...

Je commence sérieusement à douter.
Cela fait 2 semaines que je tente de faire un projet symfony 2.8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

php ./src/tools/installer new developpement 2.8

cela me génère le code.
Je prépare mon SVN ou mon GIT dans lequel je ne mets pas le dossier vendor. Logique !

je récupère dont mon projet complet de GIt dans un espace de travail et je veux reconstruire mon vendor

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

php ./src/tools/composer --working-dir=./developpement --no-dev --optimize-autoloader install

et là ERROR

An error occurred when executing the ""cache:clear --no-warmup"" command:
Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "SensioGeneratorBundle" from name
space "Sensio\Bundle\GeneratorBundle".
Did you forget a "use" statement for another namespace? in ./developpement/app/AppKernel.php:25

Le problème existe depuis au moins 2012 vu le nombre de messages sur le net
les solutions les plus farfelues sont données avec la mention résolue.
Par exemple changer le timezone du php.ini Heu le timezone qui corrige un "use" qui manque dans un code source !!! Ben ça ne marche pas
autre exemple : faire un rm -Rf du cache. Why not. Mais à priori l’use ne sera pas plus dans le fichier AppKernet.php! et ça ne marche pas plus ce qui ne m'étonne pas.
Autre solution faire un composer update

cette solution est grandiose non seulement elle change symfony de 2.8 à 3.0 elle plante sur la même erreur, mais en plus elle ne résout pas le problème.
après l'update la régénération du vendor échoue toujours.

Moi qui dois mettre en place une usine à build je suis méchamment dans la m@dr# même en suivant pas à pas les commandes du guide ça plante.
Je ne sais pas comment les gens travaille avec un tel outil, mais autour de moi je n'ai pas un développeur qui ne fait pas des récriminations à composer
et tous d'ajouter on l'utilise parce qu'on n’a pas le choix.

Depuis la mis octobre toujours pas réussis à garantir un processus de création suivit d'un build qui fonctionne à coup sûr.
On est loin de l'industrialisation des développements.

[modif]
Je crée le projet, j'exécute les tests fournis par défaut

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

php.exe./src/tools/phpunit -debug -c ./developpement/app/phpunit.xml --testdox-text ./test-report.txt

There was 1 error:

1) AppBundle\Tests\Controller\DefaultControllerTest::testIndex
Error: Class 'Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle' not found

./developpement/app/AppKernel.php:25

A+JYT
PS: Si ce n'était pas une contrainte, je mettrais tout ça à la poubelle. Avec presque 40 ans d'informatique dans les pattes je suis probablement trop vieux pour comprendre que c'est normal qu'un outil qui produit un bug en 2012 continue à le produire en 2017 et qu'aucune alternative sauf des bricolages ne soit proposée.

[Spartacusply]

Déjà, Composer est un très bon outil de gestion de dépendance et Symfony un très bon framework PHP.

Je n'utilise pas Symfony mais j'ai créé un projet en version 2.8 juste pour voir : composer create-project symfony/framework-standard-edition my_project_name "2.8.*"Déjà ma version de Symfony est fixée "symfony/symfony": "2.8.*", donc un composer update ne me fera pas passé en version 3.

Ensuite, c'est normal que tu ne puisses lancer les tests car tu as installé ton projet en utilisant l'option --no-dev et on remarque dans le composer.json :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 "require-dev": {
        "sensio/generator-bundle": "~3.0"
}

C'est de là que vienne tes deux erreurs, que ce soit pour l'install ou pour le lancement des tests. Voilà.