« Pourtant,
ça marchait en dev … »
Olivier Doucet
Fondateur et Directeur Général d’OXEVA
« It works on my laptop »
C’est quoi le sujet ?
 Anticipation des problèmes avant la mise en production
 Quelques exemples que vous avez pu rencon...
Qui suis-je ?
 Fondateur d’Oxeva, société d’hébergement avec
infogérance totale
 En charge de l’exploitation depuis dix ...
Quelques exemples
« mon site est super lent. Pourtant, aucun souci en dev »
« Le paiement ne fonctionne plus sur mon site ...
Les environnements
Les environnements
 DEV
 INTEGRATION / TEST
 PREPRODUCTION (Staging)
Le versioning
 Obligatoire, même avec un seul développeur
 Un commit par fonctionnalité
 Un message parlant
 En frança...
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 uti...
Les tests 2/3
 Tests de code fonctionnels : vérifier de manière brute les
fonctions les plus communes
 Tests d’appels pl...
Les tests 3/3
 Métrologie
Si possible, enregistrer le temps d'exécution de chaque
test
Tests de régressions (ou gains) de...
Standard de développement
 Un seul mot : lisibilité !
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 ve...
BONUS !
Quelques peaux de
bananes avec PHP et
MySQL
Quelques problèmes liés à PHP
 Opcache et les chemins de fichiers
 Taille des entiers
 MAJ des versions de PHP et cycle...
Quelques problèmes liés à MySQL
 Tester un site en étant tout seul dessus ...
 Le stockage / le cache
 Gestion des conf...
Mais aussi …
 Ne jamais sous-estimer la documentation du code !
 Pensez au Wiki interne
Votre TODO
 Ayez plusieurs environnements séparés et cloisonnés
 Versionnez son code
 Les tests unitaires ne sont pas j...
C’est le moment pour les questions !
MERCI !
Pour rester en contact :
odoucet@oxeva.fr
@ezameku
www.olivierdoucet.info
Prochain SlideShare
Chargement dans…5
×

ça marchait pourtant en dev

499 vues

Publié le

La majorité des problèmes rencontrés en production auraient pu être anticipées en amont. Rapide aperçu du process entre le développement et la mise en production.

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
499
Sur SlideShare
0
Issues des intégrations
0
Intégrations
36
Actions
Partages
0
Téléchargements
9
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Les problèmes rencontrés en production auraient pu, dans la très grande majorité des cas, être anticipés en amont
  • C’est super compliqué mais on s’en fout !
  • DEV : Un pour chaque développeur avec sa BDD séparée, outils de debugging, logs verbeux, etc.
    Intégration : on fusionne le code de chacun et on lance les tests
    Préproduction (staging) : proche de l'environnement de production : réglage de l'appli en PROD, donc pas de debug / logs minimum, configuration serveur ISO à la prod (versions des logiciels, etc.)
  • Pas de commit « jour », « heure », ou « quand j’y pense »
    Savoir quel commit casse quoi
  • 7 MIN EN ARRIVANT ICI On pourrait parler de la méthodo projet « test driven » … mais non
  • JS, calques visibles, etc.
    Penser à une commande complète pour du ecommerce ! Utiliser les api de test données par les marchands
    Cf bugs de callbacks
    Screenshot : faire ça avec PhantomJS + ImageMagick « compare »
  • Avec ça, attention lorsque vous changez le serveur de dev ("chouette les tests sont beaucoup plus rapides maintenant")
  • « coding standard » : Pour rendre tout ça lisible lorsque l'équipe s'agrandit, on choisit un coding standard et on s'y tient.
    Indentation : 2 espaces, 4, 8 ou tab ? Le premier troll du développeur
  • AVANT 13 MINUTES Si vous cherchez un moment avec trafic creux, le meilleur moment est en fait le dimanche soir tard ou lundi matin.
  • 17min grand max !
  • Xdebug: : grosse influence sur les perfs, donc tests de charge complètement erronés

    (attention aux options de compilation de PHP qui peuvent changer son comportement, notamment avec les histoires d'accents dans les images ou l'encodage des fichiers PHP)
    Gestion des erreurs => agréger les erreurs ? plutôt qu'un log de 20Go ... => jamais lu en fichier, puis oublié, puis "comment exploser l'usage disque"

    Méthode FB : profiler 1/1000e des requêtes et remonter le tout dans une interface unifiée.
  • la puissance de son ordi de test
    Serveur perso i7-3770 @ 3.4 Ghz (4 cores)
    => parfois plus rapide qu'un serveur de prod (qui compensera avec plus de cores pour plus de traitement en parallèle)
    Tuning et (et l’intérêt d’une préproduction identique)
  • est tellement pratique. Evite de vous faire déranger pendant les vacances car "on sait pas où est tel truc".
  • 50% du temps de dev devrait être assignés aux tests
  • ça marchait pourtant en dev

    1. 1. « Pourtant, ça marchait en dev … » Olivier Doucet Fondateur et Directeur Général d’OXEVA
    2. 2. « It works on my laptop »
    3. 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. 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. 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. 6. Les environnements
    7. 7. Les environnements  DEV  INTEGRATION / TEST  PREPRODUCTION (Staging)
    8. 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. 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. 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. 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. 12. Standard de développement  Un seul mot : lisibilité !
    13. 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. 14. BONUS ! Quelques peaux de bananes avec PHP et MySQL
    15. 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. 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. 17. Mais aussi …  Ne jamais sous-estimer la documentation du code !  Pensez au Wiki interne
    18. 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. 19. C’est le moment pour les questions !
    20. 20. MERCI ! Pour rester en contact : odoucet@oxeva.fr @ezameku www.olivierdoucet.info

    ×