Devops - Retour d'expérience

Présentation au LyonJUG sur les retours d'expérience DevOps. Outillage mais surtout culture et humain

Transcript

1. Devops Retour d'expérience LyonJUG 20 Décembre 2011
2. Henri Gomez +20 ans dans l’industrie logicielle Architecte Java, CI et direction de production Dev, QA et Ops OpenSource Activist Apache Tomcat JPackage openjdk-osx-build
3. DevOps en une image
4. Ce que n’est pas DevOps Un produit (même si…) Une personne ou équipe Une méthodologie stricte Une recette miracle
5. Ce qu’est DevOps Un mouvement Un incubateur Un mode agile sur l’ensemble de la chaine Une nouvelle donne technique Une autre approche humaine
6. Le mouvement DevOps Initié fin 2009 par des acteurs du monde Web Google, Amazon, Yahoo, LinkedIn, Netflix Des décideurs qui sont des technophiles
7. Nouvelles problématiques Déploiement régulier Déploiement massif Cloud
8. Agilité sur la chaine Les méthodes agiles ont fait leur preuve en DEV Ne pas réduire l’Agile au développement Applicables sous condition en QA et Ops Inscrire les opérations de Prod dans le processus
9. Déploiement fréquent Rassure l’ensemble des acteurs (Dev/QA/Ops) Rode la mécanique de mise en production Réduit les risques de découvertes tardives Mode itératif avec retours de QA/Ops Infra et code dans le cycle de déploiement continu
10. Nouvelle Donne Technique Scale out plutôt que Scale in Cloud aware Une touche de Dev pour les Ops Une pincée d’Ops dans les Dev
11. Ops comme Dev Infrastructure As Code (Chef, Puppet, Packages) Des Ops qui codent (Bash, Python, Ruby) Des Ops qui utilisent des outils du Dev (IDE et SCM)
12. Dev comme Ops Infrastructure As Code (Virtualisation, Vagrant) Des Devs utilisant des instances proches des cibles Des Devs qui touchent aux problématiques Ops
13. Plus d’automatisation Pour réduire les erreurs Pour gérer un nombre important de machines Pour garantir la reproductibilité
14. De l’humain Opposer les équipes mène à l’échec Lever les incompréhensions et inquiétudes Responsabiliser chacun sur l’ensemble du cycle de vie
15. Connaitre l’autre
16. Comprendre le Vocabulaire OOM, jar, war, Maven, CI Jmeter, SmokeTests, Selenium SLA, PRA, SNMP, JRMP, Firewall
17. Comprendre les peurs Manque de vision infra cible Boites noires Performances Effet de bord suite migration Reprise d’activité Plans de test tardifs
18. Comprendre les contraintes Collocation et mutualisation Tracabilité Monitoring Sécurité Backups
19. Des pistes Outillage commun Travail par paire (Dev & Ops) Immersion (Dev chez Ops)
20. Outillage commun GDM - Bugzilla/JIRA/Trac SCM - Subversion/Git Entrepôt - Nexus/Artifactory/Archiva Support documentaire léger type Wiki Jenkins Capitalisation des connaissances Suppression des réticences aux «outils des autres»
21. GDM commun Des projets Dev Des projets QA Des projets Ops
22. GDM pour OPS Une demande de déploiement est un ticket Description des opérations en cours Retours suite aux opérations
23. GDM pour OPS Les incidents de production sont des tickets Collecte des éléments en pièces attachées ou liens Qualification puis ouverture d’un ticket produit lié Suivi de l’incident jusqu’à la résolution produit
24. SCM commun Sources des applications Sources des tests Selenium/JMeter Sources des configs Ops (Puppet/Packaging) Sources des jobs Jenkins Code, tests et configs Ops accessibles à chacun
25. Entrepôt Commun Réduction des erreurs sur des jars/wars ‘customisés’ ou ‘déviants’ Une source connue et unique contrôlée par l’équipe Forge Renforce la nécessité de livraison par le Dev Rassure les équipes de QA et Ops Tous les acteurs partagent les mêmes livrables
26. Wiki commun Des espaces par équipes ou sujets Liens avec les projets GDM (ex: Confluence/JIRA) Cycle de publication simple Mise à jour en temps réel Participatif via les commentaires sur les articles Une source de documentation agile et sociale
27. Constats outillage commun Facilite la communication Permet l’échange des bonnes pratiques Favorise le partage des compétences
28. Travail par paire Définition des besoins (Dev -> Ops) Explication des contraintes (Ops -> Dev) Construction des livrables (ex packaging) Déploiement sur environnement virtualisé
29. Immersion Dev en situation chez les Ops Préparation au déploiement Support lors du déploiement Sur zone suite à incident sur déploiement
30. Pré-requis personnel Ouverture d’esprit Pouvoir sortir des vieux schémas Savoir écouter les autres Vouloir échanger avec les autres
31. Pré-requis organisationnel Adopter une gouvernance adaptée Promouvoir l’échange entre les équipes pluridisciplinaires Accepter une ‘démocratie’ plus directe
32. DevOps chez vous Détruire les cloisonnements Donner à accès à l’ensemble de l’information Encourager la participation et l’échange Analyse commune des besoins Définition conjointe de livrables clairs
33. Conclusion DevOps, c’est avant tout une culture de la communication. Il ne doit pas rester cantonné à une élite mais inclure l’ensemble des acteurs.
34. Des questions ?
35. Licences et copyright Photos et logos appartiennent à leur auteurs/ propriétaires respectifs. Contenu sous Creative Commons 3.0 http://creativecommons.org/licenses/by-nc-sa/3.0/us/