What if you cannot trust your tests? With more and more developers working on our monolith, we have a strong CI to deliver code into production: our goal is to deliver meaningful features to our customers with quality code and a stable platform. But some tests started failing randomly and this spread quickly through our codebase. Test failures block our CI and this leads to a huge waste of time and frustration when the application isn’t actually broken. We’ll explore the importance of tests, common errors that can lead to test flakiness, and strategies we have put in place to mitigate it.

Vos tests vous mettent en colère ? Vous empêchent-ils d'itérer rapidement ? De plus en plus de développeurs travaillent sur notre monolithe et certains tests ont commencé à échouer de manière aléatoire et cela s'est propagé rapidement dans notre base de code. Comme notre objectif principal est de fournir des fonctionnalités significatives à nos clients avec un code de qualité et une plateforme stable, les échecs de test bloquent notre CI. Cela entraîne une énorme perte de temps et de la frustration lorsque l'application n'est pas vraiment cassée. Ce problème était connu depuis un moment… Mais personne ne voulait s'y attaquer; le cacher sous le tapis était plus facile. Et coder des fonctionnalités est bien plus gratifiant que de corriger des tests buggés ! Au cours de cette conférence, nous verrons des exemples concrets des raisons pour lesquelles nos tests n'étaient pas satisfaisants et la manière dont nous les avons corrigés, avec des stratégies à la fois techniques et humaines.

About to finish my first year in my company, I caused not one but two incidents in production in one hour! Despite the tense moment, it was a huge learning. No one ran with their arms in the air, shouting at each other, nor began to look for culprits. Conversely, a close-knit team that helps each other reestablished the production as quickly as possible by collectively acknowledging the error made. How do we manage a production incident with peace of mind? an upstream quality process (code review, sandbox environment, functional review ...) a process for detecting and reporting incidents clear roles and responsabilities on incident management a post-mortem and concrete actions to avoid a repeating similar incident In this conference I will explain how to reduce and improve the management of your incidents and you will leave with the keys to apply this in your teams.

Sur le point de finir ma première année dans mon entreprise, j'ai provoqué pas un mais deux incidents en production en une heure ! Malgré le moment de tension, cela a été une énorme source d'apprentissage. Personne a couru les bras en l'air en criant les uns sur les autres ni s'est mit à chercher des coupables. À l'inverse une équipe soudée et qui s'entraide a réétabli la prod au plus vite en reconnaissant collectivement l'erreur commise. Comment arrive-t-on à gérer un incident en production en toute tranquilité ? un processus de qualité en amont (revue de code, un environnement de sandbox, une revue fonctionnelle) un processus de détection et déclaration des incidents un responsable de gestion des incidents et des responsables par équipes un post-mortem et des action concrètes pour éviter la reproduction de l'incident Dans cette conférence je vous expliquerai comment réduire et amériliorer la gestion de vos incidents et vous repartirez avec les clés pour appliquer cela dans vos équipes.

Comment collaborer dans une entreprise alors que le nombre de développeurs ne cesse d'augmenter ? Quels outils pour installer une vision commune au delà des visions individuelles ? Nous somme aujourd'hui plus de 150 développeurs qui construisons ensemble un produit. Un des piliers de notre entreprise est l'autonomie, nous souhaitons que nos ingénieurs soient autonomes sur la prise des décisions de façon à ce qu'il n'y ait pas un petit groupe de personnes qui bloque notre capacité à délivrer. Cependant si on laissait chaque développeur prendre des décisions tout seul nous pourrions vite créer une forte dette technique qui nous empêcherait de continuer à développer des fonctionnalités. Pour répondre à cela nous avons créé deux initiatives : les RFC (Request for Comments), semblable à ce que l'on peut voir pour le langage PHP et les CoP (Community of Practice) organisés autour de centres d'intérêts (backend, devOps, DDD ...). Cette organisation nous permet d'avoir des discussions techniques, d'en garder un historique et d'avoir une vision commune. Je vous raconterai comment cette organisation nous aide au quotidien à collaborer et vous repartirez avec les clés pour mettre cela en place dans vos équipes.

Deadlines, besoins produit, pression forte et fonctionnalités à livrer : nos projets ont besoin de nous ! L'amélioration du quotidien se perd dans un second plan, alors qu’elle a un impact majeur sur l'augmentation de notre productivité et la qualité et maintenabilité de notre code. Constatant que nous voulions augmenter notre confort de travail, nous avons, depuis plus d'un an, mis en place des réunions techniques bi-hebdomadaires pour prendre le temps de discuter de notre plateforme et nos outils, au-delà des fonctionnalités. Chaque membre de l'équipe contribue ainsi à améliorer son expérience de travail et notre produit. À travers notre vécu, nos erreurs et des exemples techniques concrets, repensez vous aussi au développement de votre produit.

Développeuse junior : première semaine. Mes collègues m'ont forcée à déployer ma première feature sur 6play ! Malgré un petit frisson, tout s'est bien passé, grâce aux outils et bonnes pratiques qui nous guident. Ce n'était que le début ! Depuis, je gère l'infrastructure de mon projet. Je choisis mes bases de données, caches, mécanismes de stockage, ressources… En prenant en compte leur coût, les modes de backups ou les compétences dans nos équipes. Et je suis libre d'expérimenter avec n'importe quel service que je voudrais tester. En un an, je suis passée de "simple développeuse" à quelqu'un qui a conscience de sa plateforme, qui monitore son code et est responsable de sa production. Comment ai-je vécu cette transition ? Comment ai-je grandi en tant que développeuse ? Vous aussi, profitez de votre nouvelle liberté : devenez DevOps !