Organisation dev web - Page 1

Ca fait un paquet de temps que je me demande comment est-ce que chacun s'organise niveau développement web, parce que je pense que je passe à côté de pas mal de choses.
Je ne parle pas vraiment de technos (même si ça va forcément impacter : on ne bosse pas de la même façon quand on est sur un serveur d'appli genre Tomcat à déployer des paquet ou quand on est avec Apache+PHP), mais plutôt de méthodes et d'outils utilisés pour le développement, la conception et le déploiement...

Je suis dans un cadre où les principaux services dont j'ai besoin sont Apache, PHP, MariaDB, les extensions PDO Oracle, OpenLDAP (et les extensions nécessaires à sa bonne utilisation).

Côté développement, j'utilise PhpStorm, à peu près out of the box (quasi rien configuré, à part quelques mots clés complémentaires comme EN COURS). J'utilise aussi SquirrelSQL et LDAP Browser/Editor pour l'accès aux données, ainsi que Freeplane, yEd et (au final surtout) LibreOffice pour tout ce qui est conception. J'ai Meld (un diff visuel) dans un coin, pour tous les fichiers hors projet.

Côté debug, je n'utilise que les outils de développement de Fx (j'ai toujours l'extension Webdeveloper, mais je ne l'utilise quasi plus), et j'ai un niveau de verbosité maximal sur PHP (c'est assez récent, auparavant ce n'était pas le cas et je passais à côté de plein de petites aberrations). Je pense que je pourrais gagner en efficacité ici avec la mise en place d'outils de debug spécialisés pour PHP, mais je n'ai jamais pris le temps de me pencher sérieusement sur la question (j'ai juste activé l'affichage des erreurs mis en forme en html pour PHP). Donc si vous avez des retours d'expérience là-dessus, je suis preneur.

Côté déploiement, c'est probablement là que je suis le plus mauvais : je travaille à la main, à coup de scp, sans versioning. Vous gérez ça comment, de votre côté ? Un serveur dédié au stockage du code, et un client sur votre poste ainsi que sur les serveurs ? Là aussi, j'avais un peu regardé du côté de git, mais ça m'a vite pris la tête...

Enfin, côté organisation et gestion des versions différentes des services (on n'arrive pas à un niveau d'homogénéité parfait sur les serveurs, et on a même des instances de PHP jusqu'en 5.3), mon poste de développement est à jour : dernières versions de tous les services,et je développe pour ces dernières versions. Ca me permet d'avoir un code qui sera le plus pérenne possible, mais ça m'oblige parfois à réécrire certaines fonctions ou à traiter des cas particuliers parce que les comportements ont changé. Cela dit, le passage de la famille PHP 5.x à 7.x sur ma machine de dev ne s'est pas fait sans mal et j'ai encore des applications entières que je ne peux tester depuis ma machine.

Voilà, je suis preneur de toute remarque, de tout conseil, de n'importe quoi, d'autant plus que je suis le seul dev/intégrateur dans mon établissement, donc je manque de possibilités d'échanges à ce sujet

C'est le moment de faire la promo de ton nid à serpents

ce soir ^^

J'ai une organisation très basique pour à peu près tout donc le seul point que je peux commenter dans ta liste est le déploiement. Je ne sais pas comment "on" fait aujourd'hui dans le web, mais les sites PHP ont une particularité : on copie souvent directement les fichiers de code plutôt que d'avoir une étape de compilation qui génère le contenu à déployer. Du coup des outils comme rsync sont suffisant pour à peu près tous les usages, mais pour yAronet je voulais aussi avoir la possibilité de "rollback" à une version précédente si je me rends compte que la version nouvellement déployée ne fonctionne pas du tout (par exemple elle a un souci qui n'apparaît que sur le serveur de prod, vu que je n'en ai pas de réplique fidèle).

Pour ça j'ai bricolé un petit outil, "creep", qui permet de déployer en se basant sur l'historique de Git : par défaut il va déployer tous les fichiers qui ont été modifiés depuis le dernier déploiement, mais il est possible de spécifier une révision antérieure pour revenir en arrière sur un déploiement. Il y a quelques autres avantages par rapport à rsync :

- Un fichier de configuration contient le ou les environnent(s) cible, du coup creep prod déploie en production, creep test déploie sur mon instance de test, etc.
- Le déploiement peut se faire par SSH ou par FTP
- Il est possible d'ajouter des traitements avant l'envoi pour certains fichiers (définis par regexp), par exemple minifier les JS, compiler les fichiers LESS et optimiser les images dans mon cas

je serais curieux de savoir s'il existe des solutions connues pour ces problèmes

Quand je fais du web (le moins possible, mais malheureusement ça m'arrive régulIèrement de faire des petites interfaces), j'ai maintenant une procédure assez bien rodée.

D'abord, les outils :
* PyCharm pour l'IDE,
* Python (3.4+, sauf cas ultra-spécifique auquel cas je pars sur du Python 2.7) dans un virtualenv,
* Github sauf projets pros, « semi-pros » (Gitlab), et vraiment perso (svn actuellement, bientôt gitlab)
* PostgreSQL + Redis (la plupart du temps) en base (je ne touche plus à du MySQL),
* Apache (faudrait que je passe à du nginx, mais j'ai la flemme)
* un maximum de tests en pur Python (unittest + hypothesis pour faire du property-based testing)
* lancement des tests unitaires via tox,
* je commence à passer à Vagrant pour lancer les tests et générer les paquets (sauf sur mon portable perso par manque d'espace disque)
* documentation (essentiellement pour l'installation) via Sphinx, uploadée dans readthedocs pour les projets publics (ou une instance Updoc pour le « semi-pro » et le perso)
* package Python uploadé dans le miroir Python officiel pour les projets publics, sinon dans une instance Moneta pour le miroir Python ou Debian perso

Je n'accepte que deux façons d'installer :
* apt-get install [monprojet] pour installer au niveau système
* pip install [monprojet] --upgrade dans un virtualenv (une sorte de chroot pour isoler toutes les libs Python du projet avec la bonne version Python)
* pour la base de données, jamais la moindre manip' à la main ou le moindre script SQL : "monprojet-manage migrate" passe à la bonne version des tables, avec la possibilité de faire un rollback
Dans tous les cas, tout doit être documenté pour que je n'ai que du copier-coller à faire.

Ça veut aussi dire aucune conf' dans le code, tout doit être dans un fichier de config propre (dans /etc), lancé via systemd, envoi des erreurs par mail, etc.

Pour (largement) me simplifier la vie, j'ai fait mon propre framework au-dessus de Django, qui me permet de :
* avoir un système de signaux permettant d'appeler du code Python (interactif ou en arrière-plan) ou JS depuis le JS, le Python en réponse à une requête HTTP ou depuis le process en arrière-plan tout en simplifiant les tests unitaires et en limitant le code JS à écrire,
* la gestion des fichiers de configuration super simple (la plupart des projets Django demandent de modifier un fichier versionné pour la conf),
* générer des paquets Debian (avec la conf systemd, supervisor, apache, nginx),
* générer les scripts pour générer les paquets Debian pour toutes les dépendances,
* générer la documentation complète (installation, mise-à-jour, backup, options pour le fichier de conf, …),
* affiche la configuration actuelle,
* faciliter le backup de la base de données,
* avoir une base Bootstrap3 fonctionnelle directement.