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
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
17. Comprendre les peurs
Manque de vision infra cible
Boites noires
Performances
Effet de bord suite migration
Reprise d’activité
Plans de test tardifs
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»
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
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
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.
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/