Le Software Craftmanship : quelle signification pour du code Puppet?

Joué au Meetup Puppet Paris @OCTO Technology le 9 juin 2015

Vidéo : http://youtu.be/Q2opUJXX_VY
Repo avec quelques exemples : https://github.com/alex-raoul/minbeaker-apache_pfs

Transcript

1. 1 © OCTO 2015 © OCTO 2015 Meetup Puppet Paris - 9 Juin 2015 - Alexandre Raoul Le Software Craftmanship : quelle signification pour du code Puppet?
2. 2 © OCTO 2015 Le Software Craftmanship? Encore un buzzword ! Et en plus, c’est un truc de dev !
3. 3 © OCTO 2015 “Le Software craftsmanship est une approche de développement de logiciels qui met l'accent sur les compétences de codage des développeurs de logiciels eux-mêmes.”
4. 4 © OCTO 2015 Mais en fait derrière, c’est l’idée … … que la mauvaise qualité a (ou aura) un coût ... qu’on ne court pas un marathon comme un sprint
5. 5 © OCTO 2015 Mais en fait derrière, c’est l’idée … ... qu’on peut toujours s’améliorer et apprendre ... que partager son savoir est une noble chose
6. 6 © OCTO 2015 C’est plus un mindset qu’une méthodologie manifesto.softwarecraftsmanship.org
7. 7 © OCTO 2015 Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus
8. 8 © OCTO 2015 Test Driven Development Collective Code Ownership Software Entropy Pair Programming Style Guide Design Patterns Lint Refactoring Coding Dojo Clean Code Test Harness Keep It Simple Stupid (KISS) Behaviour Driven Development Tech Leading Newspaper Style Broken Window Boy Scout Rule Don’t Repeat Yourself (DRY) Unit Testing Egoless Programming You Ain’t Gonna Need It (YAGNI) Separation Of Concerns (SOC) Code Review Data Separation Code Legacy Jouons au bingo !
9. 9 © OCTO 2015 Dans notre contexte, c’est bien conçu si … “ça fait que ça dit et ça dit ce que ça fait” Keep It Simple Stupid (KISS) Exemple : un module mysql, n’installe que mysql, pas emacs en plus parceque les DBA préferent
10. 10 © OCTO 2015 Dans notre contexte, c’est bien conçu si … “je comprends comment ça marche” Clean Code Exemple : on fait du puppet avec “package”, “file” etc pas des oneliner shell de 400 signes dans un exec Exemple : on n’abuse pas de l’héritage, des ancres partout ou des collecteurs pour modifier des ressources
11. 11 © OCTO 2015 Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur
12. 12 © OCTO 2015 Coût Périmètre Délais Qualité
13. 13 © OCTO 2015 Exemple d’axes de valeurs … … pour les utilisateurs, le module java gère java 8 ! … pour les adminsys, le module java est tellement bien fait que je suis serein pour mon OS
14. 14 © OCTO 2015 Exemple d’axes de valeurs … … pour l’équipe sécurité, intégrer des confs durcies par défaut dans le module Apache … pour les astreintes, des noms de modules tellement clairs que le rapport Puppet devient la référence quand on se réveille à 3h
15. 15 © OCTO 2015 Pour les formaliser, on peut utiliser les user stories “Je développe ${telle fonctionnalité} pour que ${telle personne} puisse effectuer ${telle action} qui a du sens parce que ${telle plus value}”
16. 16 © OCTO 2015 Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels
17. 17 © OCTO 2015 En tant que tech lead … … ne pas contraindre votre équipe mais montrer l’exemple
18. 18 © OCTO 2015 En tant que tech lead … … en montrant que vous continuez d’ apprendre, que le chemin ne finit jamais
19. 19 © OCTO 2015 Au niveau de votre équipe … … des revues de codes ... … du pair programming pour améliorer le “collective code ownership” ... … et des coding dojo pour faire progresser tout le monde
20. 20 © OCTO 2015 Au niveau de votre boîte … … partager votre veille avec vos collègues, … partager votre savoir avec des BBL (Brown Bag Lunch)
21. 21 © OCTO 2015 Au niveau de la communauté dans son ensemble … … en contribuant avec des Pull Requests et en ouvrant votre code … en participant aux meetups !
22. 22 © OCTO 2015 Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs
23. 23 © OCTO 2015 La focalisation sur des deadlines arbitraires… Ne perdez pas d'énergie là dedans “Faut absolument livrer pour le 30 juin” “Pourquoi?” “Parce que dans la roadmap d’octobre, on a dit que c’était un projet du 2e trimestre !”
24. 24 © OCTO 2015 La focalisation sur le nom du poste... Souvent associé avec la paperasserie aigüe ! Soyez efficients, aller voir les bonnes personnes directement “Pour faire X, il faut demander la validation à Y et Z doit valider l’architecture”
25. 25 © OCTO 2015 Si vous n’avez pas expliqué votre démarche… Vous passerez votre temps à vous justifier “Faire des tests? Tester c’est douter !” “Vous avez besoin de quoi? Faire du refactoring??” “Ça marche, pourquoi revenir dessus?
26. 26 © OCTO 2015 Exprimez clairement pourquoi votre équipe existe pour se recentrer sur l’essentiel Quel est le WHY de votre équipe? “Maintenir le SLA dans les clous” ? “Réduire le Time To Market du métier” ?
27. 27 © OCTO 2015 Échangez avec les Dev ! Imaginez : au lieu de demander un accès root sur la prod, un dev fait une Pull Request sur votre code Puppet
28. 28 © OCTO 2015 Et concrètement, on peut utiliser quoi pour tester du code Puppet?
29. 29 © OCTO 2015 Tester du code son Puppet ou tester son infrastructure?
30. 30 © OCTO 2015
31. 31 © OCTO 2015 Le code Puppet n’a pas tout à fait les mêmes propriétés que du python/java/autre langage Souvent, la difficulté/fragilité réside dans l’ installation/configuration/exploitation d’un composant Au lieu de principalement refactorer une fonction de 20-50 lignes, on va refactorer une classe de 300 lignes
32. 32 © OCTO 2015 L’analyse statique pour vérifier très vite la syntaxe et le style Éviter de commiter/pusher du code avec une erreur de syntaxe ou une indentation foireuse (surtout le vendredi soir)
33. 33 © OCTO 2015 • S’assurer de la syntaxe du code produit OBJECTIFS Vérifie la syntaxe : • .pp avec le Puppet DSL • .erb templates ruby DSL • .yml fichiers hiera YAML • .rb plugins en Ruby FONCTIONNEMENT • Ça ne vérifie que la syntaxe, pas que les commandes existent OÙ EXÉCUTER ? Secondes TEMPS D'EXÉCUTION Serveur d’intégration continue Pre-commit hook sur les postes de travail POINTS CLÉS Carte d’identité : Puppet files parser
34. 34 © OCTO 2015 • Vérifie que les règles de style sont bien suivies OBJECTIFS Vérifie des choses comme : • Tabs au lieu des double espaces • String avec double quote sans variable dedans • Paramètres dupliqués dans les ressources • Switch case sans case par défaut • “ensure” qui n’est pas le premier paramètre • … FONCTIONNEMENT • Utilise les conventions de la communauté • Possibilité d’étendre avec ses propres règles OÙ EXÉCUTER ? Secondes TEMPS D'EXÉCUTION Serveur d’intégration continue Pre-commit hook sur les postes de travail POINTS CLÉS Carte d’identité : Puppet Lint
35. 35 © OCTO 2015
36. 36 © OCTO 2015 Du test unitaire pour vérifier très vite la logique du code n’est pas perdue Particulièrement utile pour conserver l’ intention lors de l'écriture d’un profile Ou pour écrire des modules ultra polyvalents (comme ceux de puppetlabs)
37. 37 © OCTO 2015 • Vérifie ce que le module est censé faire dans différentes situations (OS, paramètres d’entrée) • Cela va valider la logique algorithmique (if/else), la propagation de variables... OBJECTIFS 1) Puppet compile un catalogue avec certains facts (c’est l’idée, pas exactement ce qui est fait) 2) RSpec-Puppet compare ce qu’il y a dans le catalogue et ce que les tests disent FONCTIONNEMENT • Le plus difficile est de ne pas traduire son code dans un autre langage… • Les tests ne tournent pas sur une vraie machine : si le package n’existe pas, ça ne le dira pas OÙ EXÉCUTER ? 2 secondes à 2 minutes TEMPS D'EXÉCUTION Serveur d’intégration continue Pre-commit hook sur les postes de travail POINTS CLÉS Carte d’identité : RSpec-Puppet
38. 38 © OCTO 2015
39. 39 © OCTO 2015 Du test d’intégration pour vérifier que le module fonctionne bien en vrai Attention, il y a certains pré-requis au niveau de votre SI : création de VM via API, isolation des environnements etc
40. 40 © OCTO 2015 • S’assurer que le code Puppet fournit une infrastructure utilisable • S’assurer que le code est bien idempotent OBJECTIFS 1) Demande une VM (vagrant, AWS, voir même Docker) 2) Applique le module Puppet 3) Verifie à l’aide de Serverspec que tout est ok FONCTIONNEMENT • L’idée est de tester les voies royales • L’idée est d’automatiser ce que vous testez manuellement : création d’une vm, puppet apply, netstat + ps pour vérifier que ça tourne ... OÙ EXÉCUTER ? 2 minutes (docker simple) à plusieurs dizaines de minutes TEMPS D'EXÉCUTION Serveur d’intégration continue POINTS CLÉS Carte d’identité : Beaker
41. 41 © OCTO 2015
42. 42 © OCTO 2015 Et des outils hors écosystème Puppet L’idée : on crée un environnement plus ou moins complet (lab) avec Puppet et on en vérifie le comportement.
43. 43 © OCTO 2015 Système de supervision Chaos Monkey pour vérifier la résilience Tir de performances via Gatling Scénarios de pentests ou vérification de conformité SCAP pour la sécurité Tests end-to-end des applications déployées
44. 44 © OCTO 2015 Avec tout ça, on a la boîte à outils pour faire du Test Driven Development sur de l’infrastructure Test Driven Infrastructure
45. 45 recrutement@octo.com Vous croyez que les technologies changent le monde ? Nous aussi ! Rejoignez-nous !
46. On propose des formations ! Adopter les bonnes pratiques DevOps appliquées aux échanges Formations PuppetLabs officielles Software Craftmanship Et plein d’autres