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?
   

   View Slide

2. 2
   © OCTO 2015
   Le Software Craftmanship?
   Encore un buzzword !
   Et en plus, c’est un truc de dev !
   

   View Slide

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.”
   

   View Slide

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
   

   View Slide

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
   

   View Slide

6. 6
   © OCTO 2015
   C’est plus un mindset qu’une méthodologie
   manifesto.softwarecraftsmanship.org
   

   View Slide

7. 7
   © OCTO 2015
   Pas seulement des logiciels
   opérationnels, mais aussi
   des logiciels bien conçus
   

   View Slide

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 !
   

   View Slide

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
   

   View Slide

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
    

    View Slide

11. 11
    © OCTO 2015
    Pas seulement l'adaptation aux
    changements, mais aussi
    l'ajout constant de la valeur
    

    View Slide

12. 12
    © OCTO 2015
    Coût
    Périmètre Délais
    Qualité
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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}”
    

    View Slide

16. 16
    © OCTO 2015
    Pas seulement les individus et
    leurs interactions,
    mais aussi une communauté de
    professionnels
    

    View Slide

17. 17
    © OCTO 2015
    En tant que tech lead …
    … ne pas contraindre votre
    équipe mais montrer l’exemple
    

    View Slide

18. 18
    © OCTO 2015
    En tant que tech lead …
    … en montrant que vous continuez d’
    apprendre, que le chemin ne finit jamais
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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 !
    

    View Slide

22. 22
    © OCTO 2015
    Pas seulement
    la collaboration avec les clients,
    mais aussi
    des partenariats productifs
    

    View Slide

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 !”
    

    View Slide

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”
    

    View Slide

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?
    

    View Slide

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” ?
    

    View Slide

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
    

    View Slide

28. 28
    © OCTO 2015
    Et concrètement, on peut utiliser
    quoi pour tester du code Puppet?
    

    View Slide

29. 29
    © OCTO 2015
    Tester du code son Puppet
    ou tester son infrastructure?
    

    View Slide

30. 30
    © OCTO 2015
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

35. 35
    © OCTO 2015
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

38. 38
    © OCTO 2015
    

    View Slide

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
    

    View Slide

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
    

    View Slide

41. 41
    © OCTO 2015
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

45. 45
    recrutement@octo.com
    Vous croyez que les technologies changent le
    monde ?
    Nous aussi ! Rejoignez-nous !
    

    View Slide

46. On propose des formations !
    Adopter les bonnes pratiques DevOps appliquées aux
    échanges
    Formations PuppetLabs officielles
    Software Craftmanship
    Et plein d’autres
    

    View Slide