La présentation de Henri Gomez sur DevOps aborde son essence en tant que mouvement et mode agile qui transcende les méthodologies classiques, en mêlant développement, qualité et opérations. Elle souligne l'importance de la collaboration, de l'automatisation et de l'échange de compétences pour améliorer les processus de déploiement et de gestion des incidents, tout en favorisant une culture de communication au sein des équipes. En conclusion, DevOps doit englober tous les acteurs, visant à réduire les cloisonnements et à promouvoir le partage d'informations.

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/