Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Le Software Craftmanship : quelle signification pour du code Puppet?

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

Alexandre RAOUL

June 09, 2015
Tweet

More Decks by Alexandre RAOUL

Other Decks in Programming

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. 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 !
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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}”
  12. 16 © OCTO 2015 Pas seulement les individus et leurs

    interactions, mais aussi une communauté de professionnels
  13. 17 © OCTO 2015 En tant que tech lead …

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

    … en montrant que vous continuez d’ apprendre, que le chemin ne finit jamais
  15. 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
  16. 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)
  17. 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 !
  18. 22 © OCTO 2015 Pas seulement la collaboration avec les

    clients, mais aussi des partenariats productifs
  19. 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 !”
  20. 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”
  21. 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?
  22. 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” ?
  23. 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
  24. 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
  25. 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)
  26. 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
  27. 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
  28. 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)
  29. 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
  30. 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
  31. 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
  32. 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.
  33. 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
  34. 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
  35. On propose des formations ! Adopter les bonnes pratiques DevOps

    appliquées aux échanges Formations PuppetLabs officielles Software Craftmanship Et plein d’autres