Recomendados
Recomendados
Más contenido relacionado
Similar a Développeur ta prod tu respecteras !
Similar a Développeur ta prod tu respecteras ! (20)
Développeur ta prod tu respecteras !
- 1. DÉVELOPPEUR, TA PROD DÉVELOPPEUR, TA PROD TU RESPECTERAS ! TU RESPECTERAS ! 1
- 4. POURQUOI ? QUOI ? POURQUOI ? QUOI ? Pourquoi cette conférence ? Retours d’expériences Plein d’anecdotes Pas mal de projets On va parler de quoi ? Toute la vie du projet… Du build aux incidents de prod.. en passant par la première MEP 4
- 6. 6
- 8. LA DREAM TEAM LA DREAM TEAM D’HAMSTERGRAM D’HAMSTERGRAM 8
- 11. LE BUILD LE BUILD Il ne faut pas confondre vitesse et précipitation 9
- 12. GIT GIT On va vous faire un dessin ? Plus sérieusement, il faut faire ça propre Config: Protéger des branches, des tags Prévoir un système de version Instaurer un workflow 10
- 13. INITIALISER UN SUPPORT DE INITIALISER UN SUPPORT DE DOCUMENTATION DOCUMENTATION Pour git et le workflow: ça se documente Les "futurs vous" ne doivent pas se poser la question du workflow et du nommage. Doc technique / process Prévoir que l’équipe peut évoluer avec le temps Le Readme c’est déjà de la doc C’est facile à mettre à jour ! 11
- 14. READY, READY, SET, GO ! SET, GO ! 12
- 15. READY, READY, SET, GO ! SET, GO ! 12
- 16. LET’S TALK ABOUT TESTS LET’S TALK ABOUT TESTS 13
- 17. LES TESTS, C’EST IMPORTANT ? LES TESTS, C’EST IMPORTANT ? Maintenabilité et évolutivité Facilite le développement .. Les montées de versions (moteurs/libs) .. Les passes de non-regression Stabilité de l’application Représente (normalement) l’attendu d’une feature 14
- 18. VALORISER LES TESTS: VALORISER LES TESTS: AUTOMATISER AVEC LA CI AUTOMATISER AVEC LA CI Ecrire des tests, c’est bien Lancer les tests, c’est mieux Les lancer le plus souvent possible c’est encore mieux 15
- 20. L’AUTOMATISATION EST PLUS L’AUTOMATISATION EST PLUS QU’UN GAIN DE TEMPS QU’UN GAIN DE TEMPS Taches répétitives Documentation et process vivants un test = comment ça doit marcher script = ce que j’aurai du faire à la main Facilite le (re)démarrage Anticipe le passage à l’échelle du projet 17
- 21. AUTOMATISER LA LIVRAISON AUTOMATISER LA LIVRAISON On automatise le provisionnement Infra As Code ou au moins Config As Code Même sur le poste de dev On automatise la livraison Sur tous les envs ! Promotion du livrable 18
- 22. COHÉRENCE DES COHÉRENCE DES ENVIRONNEMENTS ENVIRONNEMENTS Versions BD / moteur applicatif OS Version applicative Cohérence des données ! Note C’est facile si tout est automatisé ! 19
- 23. GESTION DES DONNÉES : GESTION DES DONNÉES : STRUCTURE DE DONNÉES STRUCTURE DE DONNÉES La structure de la base de données se versionne comme le code Comme pour git, utiliser un système de changement unitaire de la base Liquibase est une solution Outil permettant d’appliquer des modifications à la base de données Écriture de ces changements en xml, json, yaml ou sql 20
- 24. LIQUIBASE LIQUIBASE <changeSet author=”Bob” id=”157”> <createTable tableName=”person”> <column autoIncrement=”true” name =”id” type=”INTEGER”> <constraints nullable=”false” primaryKey=”true” primaryKeyName= </column> <column name=”firstname” type=”VARCHAR(50)”/> <column name=”lastname” type=”VARCHAR(50)”> <constraints nullable=”false”/> </column> <column name=”state” type=”CHAR(2)”/> <column name=”username” type=”VARCHAR(8)”/> <column name=”column1” type=”VARCHAR(8)”/> <column name=”column2” type=”VARCHAR(8)”/> </createTable> </changeSet> 21
- 25. A QUOI ÇA NOUS SERT A QUOI ÇA NOUS SERT Mettre à jour la structure à chaque version Eviter les erreurs humaines (pas de script lancé à la main) Etre sûr que chaque environnement est dans la bonne version 22
- 26. BONNES PRATIQUES BONNES PRATIQUES Bien séparer les scripts par versions applicatives Avoir des changements atomiques Gérer par profil les différents environnements S’assurer de l’idempotence 23
- 27. ET LE ROLLBACK ? ET LE ROLLBACK ? DB relationnelle: pas glop ! Attention aux : Suppression Renommage de table ou colonnes Rollback pas géré par les outils Il vaut mieux le faire en 2 temps nouvelle colonne + copie Suppression après la livraison / à la version suivante Note Un rollback ça se teste ! 24
- 28. À RETENIR À RETENIR Tests écrits ✓ Tests automatisés ✓ Déploiement automatisé ✓ 25
- 29. VERS LA MEP ET AU DELÀ VERS LA MEP ET AU DELÀ 26
- 30. MISE EN PROD : CEINTURE ET MISE EN PROD : CEINTURE ET BRETELLES BRETELLES Sécurisation des données avec un dump de bases Et des media si besoin Prévoir un rollback .. Tester le rollback avant de passer en prod ! 27
- 31. LE VRAI PASSAGE EN PROD LE VRAI PASSAGE EN PROD 28
- 32. LE VRAI PASSAGE EN PROD LE VRAI PASSAGE EN PROD 28
- 33. À RETENIR À RETENIR Livrer souvent ✓ Automatiser ✓ Versionner ✓ Tester les restaurations ✓ 29
- 34. LA PROD, ÇA S’ENTRETIENT ! LA PROD, ÇA S’ENTRETIENT ! 30
- 35. CE QUI CHANGE QUAND ON CE QUI CHANGE QUAND ON PASSE EN MODE RUN PASSE EN MODE RUN 31
- 36. LE WORKFLOW DE TRAVAIL LE WORKFLOW DE TRAVAIL Avant on priorisait et on prenait les retours de recette. Maintenant, il faut gérer les retours utilisateurs ou memes les alertes de l’exploitation. Comment on apporte un hotfix ? Il faut attendre la prochaine release dans 2 semaines ? Tout ce qui est développé passera (rapidement) en prod. 32
- 37. LES DONNÉES LES DONNÉES En mode build on utilise des données construites depuis liquibase ou un import En mode run, on a: Plus de volume (DB, Media, etc …) Des données venant de la vie applicative… Plus ou moins cohérentes Plus ou moins attendues Qu’il faut souvent obfusquer 33
- 38. PREPROD ISO PROD ? PREPROD ISO PROD ? Idéalement, on se rapproche le plus possible de l’ISO : en infra en applicatif en données Mais difficile de tout reproduire : Volumétrie des activités utilisateurs Crawlers de référencement etc .. 34
- 39. ACCÈS AUX BASES DE DONNÉES ACCÈS AUX BASES DE DONNÉES Règles à respecter : Pas d’accès en écriture sur la base de production Pas de commit auto Respect de l’architecture pour se connecter (accès sécurisé) 35
- 40. ACCÈS AUX BASES DE DONNÉES ACCÈS AUX BASES DE DONNÉES Les développeurs NE DOIVENT PAS avoir accès à la base de production 36
- 41. LES INCIDENTS ÇA ARRIVE LES INCIDENTS ÇA ARRIVE TOUJOURS Opportunité pour apprendre et améliorer son système. Il faut savoir les traiter ressources temps process 37
- 42. L’IMPORTANCE DE POST L’IMPORTANCE DE POST MORTEM / RETEX MORTEM / RETEX Résoudre un incident c’est bien. Eviter qu’il se reproduise et en tirer des actions/enseignement Temps d’échange à chaque crise en prod REX, Post-Morten .. Prévoir actions préventives Améliorer code, monitoring, observabilité .. 38
- 43. VERSIONS : ON VEILLE AU GRAIN VERSIONS : ON VEILLE AU GRAIN On choisit des versions up to date au démarrage Durant toute la vie de l’appli, on surveille : Vulnérabilités des librairies Vulnérabilités des envrionnements (db, java, php, serveur web ..) Vulnérabilités dans les OS Disparition de librairies 39
- 44. À RETENIR À RETENIR Adapter son organisation ✓ Prendre conscience que c’est notre métier ✓ Prévoir des process pour gérer les incidents ✓ Veiller à ses versions ✓ 40
- 45. ET SI FAISAIT MIEUX ? ET SI FAISAIT MIEUX ? 41
- 46. MIEUX GÉRER SON MONITORING MIEUX GÉRER SON MONITORING 42
- 47. LOGS LOGS Les logs sont un rouage essentiel de la production Il faut une vraie stratégie de logs Comment les mettre en place ? Manuellement pour des cas métiers précis Utilisation d’AOP (Programmation par Aspect) pour généraliser les logs techniques Il faut pouvoir lier les logs (utilisation d’un id de corrélation) 43
- 48. DES LOGS POUR LE FRONT ! DES LOGS POUR LE FRONT ! Penser aussi à mettre en place des logs pour la partie front Comment faire ? Exposer un endpoint sur lequel on envoie les logs du front afin qu’ils soient agrégés 44
- 49. DES MÉTRIQUES ! DES MÉTRIQUES ! Il faut avoir diverses métriques sur notre application : Métier Performance (temps de réponse) Celles-ci peuvent être générées automatiquement mais on peut aussi en rajouter des personnalisées 45
- 50. OUTILS OUTILS APM (Application Performance Manager) et monitorings : Glowroot Skywalking Blackfire NewRelic Prometheus etc … En Java : spring-actuator 46
- 51. DU MONITORING À DU MONITORING À L’OBSERVABILITÉ L’OBSERVABILITÉ A quoi vont servir tous ces logs ? Toutes ces métriques ? Qui va les utiliser ? L’observabilité, c’est connaitre l’état de son système à tout instant, juste avec la télémétrie. 47
- 52. APPORTER DU CHANGEMENT APPORTER DU CHANGEMENT sans (trop) mettre en prod Feature Flipping: livrer une feature désactivée ON / OFF Le versionning d’API Rétro compatible / multi-versions Dans tous les cas, cela peut être compliqué avec une base relationnelle ! 48
- 53. PIMP MY CI: PLUS DE TESTS ! PIMP MY CI: PLUS DE TESTS ! Tests de sécurité OWASP proxy Top ten OWASP en analyse statique Tests de charge / de perf gatling .. Chaos engineering Monkey testting 49
- 54. À RETENIR À RETENIR Rajouter des logs pertinent ✓ Penser au monitoring ✓ Toujours s’améliorer ✓ 50
- 55. CONCLUSION CONCLUSION Respecter sa prod .. ça se passe à tout moment du projet par chaque membre de l’équipe ça permet de se simplifier la vie On peut toujours s’améliorer, mais il faut trouver l’équilibre 51
- 56. CONCLUSION CONCLUSION Et les Ops ? Avec devops, on fait tout AS CODE donc même principe ! Et pour l’infra ? On en parlera peut-être plus tard 52
- 57. CONCLUSION CONCLUSION Et les Ops ? Avec devops, on fait tout AS CODE donc même principe ! Et pour l’infra ? On en parlera peut-être plus tard 52
- 58. ET VOUS ? ET VOUS ? Vos expériences vécues ? Vos conseils ? Vos questions ? 53