Olivier Doucet, fondateur d'Oxeva, aborde l'importance de l'anticipation des problèmes techniques en développement PHP/MySQL avant la mise en production. Il met en avant les bonnes pratiques comme le versioning, l'exécution de tests unitaires et fonctionnels, ainsi que la nécessité d'une organisation rigoureuse pour éviter les problèmes courants. Doucet insiste également sur la documentation et la séparation des environnements comme clés du succès en développement web.

1. « Pourtant,
ça marchait en dev … »
Olivier Doucet
Fondateur et Directeur Général d’OXEVA

2. « It works on my laptop »

3. C’est quoi le sujet ?
 Anticipation des problèmes avant la mise en production
 Quelques exemples que vous avez pu rencontrer …
 Organisation et bonnes pratiques pour pallier ces
problèmes
 Petite sélection des pièges déjà rencontrés sur les
technologies PHP / MySQL

4. Qui suis-je ?
 Fondateur d’Oxeva, société d’hébergement avec
infogérance totale
 En charge de l’exploitation depuis dix ans
 Expert PHP / MySQL
 Animation de conférences et formations

5. Quelques exemples
« mon site est super lent. Pourtant, aucun souci en dev »
« Le paiement ne fonctionne plus sur mon site e-commerce ! »
« mon développeur a voulu modifier cette fonctionnalité super
simple et là ça marche pas, ça doit venir du serveur »
« la base de données plante sans arrêt »

6. Les environnements

7. Les environnements
 DEV
 INTEGRATION / TEST
 PREPRODUCTION (Staging)

8. Le versioning
 Obligatoire, même avec un seul développeur
 Un commit par fonctionnalité
 Un message parlant
 En français, anglais ou Klingon, mais tout le monde suit la
même langue
 Utilisation des concepts de branches et tags
 Chaque commit va mettre à jour « testing » et va subir des
tests
https://xkcd.com/1296/

9. Les tests 1/3
 Réalisation de tests unitaires avec données de fixtures
 Basés sur ce qui est prévu dans le framework utilisé
 Couplage de ces tests dans un outil de tracking des
modifications (Jenkins, Bamboo)
 Exécution des tests pour chaque commit ou release
 Anticiper tout bug avant d’arriver en prod …

10. Les tests 2/3
 Tests de code fonctionnels : vérifier de manière brute les
fonctions les plus communes
 Tests d’appels plus complexes
 Scénarios "humains" : Simulation d’un vrai navigateur
 Tests JavaScript, DOM, …
 Possibilité de tests multi-navigateurs avec capture
d’écrans
 Quelques tests HTTP / HTTPS ?

11. Les tests 3/3
 Métrologie
Si possible, enregistrer le temps d'exécution de chaque
test
Tests de régressions (ou gains) de perfs

12. Standard de développement
 Un seul mot : lisibilité !

13. La mise en production
 J’utilise un tag git dûment testé et approuvé
 Je m’en occupe un vendredi soir
 Je fait ça un vendredi soir parce que mon patron insiste
 J’ai préparé un scénario de retour-arrière en cas de
problème
 J’ai vérifié que j’avais une sauvegarde de toutes les
données

14. BONUS !
Quelques peaux de
bananes avec PHP et
MySQL

15. Quelques problèmes liés à PHP
 Opcache et les chemins de fichiers
 Taille des entiers
 MAJ des versions de PHP et cycles de release
 Xdebug Gestionnaire d'erreur personnalisé
 Du profiling en prod ? La méthode "Facebook"

16. Quelques problèmes liés à MySQL
 Tester un site en étant tout seul dessus ...
 Le stockage / le cache
 Gestion des configurations développement et production
 JAMAIS d’accès en dur dans GIT …
 Séparer les fichiers et les bases
 Tuning de la production par un professionnel

17. Mais aussi …
 Ne jamais sous-estimer la documentation du code !
 Pensez au Wiki interne

18. Votre TODO
 Ayez plusieurs environnements séparés et cloisonnés
 Versionnez son code
 Les tests unitaires ne sont pas juste pour faire plaisir
 Suivez un standard de syntaxe
 Créez un vrai processus de release
 Bossez avec des gens compétents ^^
Toute cette présentation ne doit pas vous empêcher de respecter le bon adage :
« Release early, release often »

19. C’est le moment pour les questions !

20. MERCI !
Pour rester en contact :
odoucet@oxeva.fr
@ezameku
www.olivierdoucet.info