20111220 lyon jug-devops-culture

DevopsRetour d'expérienceLyonJUG 20 Décembre 2011

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

DevOps en une image

Ce que n’est pas DevOps

Un produit (même si…)

Une personne ou équipe

Une méthodologie stricte

Une recette miracle

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

Le mouvement DevOps

Initié fin 2009 par des acteurs du monde Web

Google, Amazon, Yahoo, LinkedIn, Netflix

Des décideurs qui sont des technophiles

Nouvelles problématiques

Déploiement régulier

Déploiement massif

Cloud

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

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

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

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)

Dev comme Ops

Infrastructure As Code (Virtualisation, Vagrant)

Des Devs utilisant des instances proches des cibles

Des Devs qui touchent aux problématiques Ops

Plus d’automatisation

Pour réduire les erreurs

Pour gérer un nombre important de machines

Pour garantir la reproductibilité

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

Connaitre l’autre

Comprendre le Vocabulaire

OOM, jar, war, Maven, CI

Jmeter, SmokeTests, Selenium

SLA, PRA, SNMP, JRMP, Firewall

Comprendre les peurs

Manque de vision infra cible

Boites noires

Performances

Effet de bord suite migration

Reprise d’activité

Plans de test tardifs

Comprendre les contraintes

Collocation et mutualisation

Tracabilité

Monitoring

Sécurité

Backups

Des pistes

Outillage commun

Travail par paire (Dev & Ops)

Immersion (Dev chez Ops)

Outillage commun

GDM - Bugzilla/JIRA/Trac

SCM - Subversion/Git

Entrepôt - Nexus/Artifactory/Archiva

Support documentaire léger type Wiki

Jenkins

Capitalisation des connaissancesSuppression des réticences aux «outils des autres» 

GDM commun

Des projets Dev

Des projets QA

Des projets Ops

GDM pour OPS

Une demande de déploiement est un ticket

Description des opérations en cours

Retours suite aux opérations

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

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

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

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

Constats outillage commun

Facilite la communication

Permet l’échange des bonnes pratiques

Favorise le partage des compétences

Travail par paire

Définition des besoins (Dev -> Ops)

Explication des contraintes (Ops -> Dev)

Construction des livrables (ex packaging)

Déploiement sur environnement virtualisé

Immersion

Dev en situation chez les Ops

Préparation au déploiement

Support lors du déploiement

Sur zone suite à incident sur déploiement

Pré-requis personnel

Ouverture d’esprit

Pouvoir sortir des vieux schémas

Savoir écouter les autres

Vouloir échanger avec les autres

Pré-requis organisationnel

Adopter une gouvernance adaptée

Promouvoir l’échange entre les équipes pluridisciplinaires

Accepter une ‘démocratie’ plus directe

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

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.

Des questions ?

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/