SlideShare une entreprise Scribd logo
DevOps @ Eutelsat – 28-juin
DEVOPS
UN TOUR D’HORIZON
LE SPEAKER
Ludovic Piot
@lpiot
Agenda
UNE TENTATIVE DE DÉFINITION
▪ Pourquoi un tel engouement ?
▪ Disclaimer
▪ Une proposition de définition
LES ORIGINES
▪ le mur de la confusion
▪ le mouvement agile : exemple à suivre
▪ le mur de la confusion
OPS, THE FINAL FRONTIER
▪ la software factory : terrain de réconciliation
KNOWING THE PATH VS. WALKING THE PATH
▪ DevOps is... / is not…
▪ TRS
▪ Tools
▪ Pistes de mise en œuvre
DEVOPS
Une tentative de définition
DEVOPS – pourquoi un tel engouement ?
Source:StateofDevOpsreport2016-2017
(Puppet+DevopsResearch&Assessment)
DEVOPS – pourquoi un tel engouement ?
Source:StateofDevOpsreport2016
(Puppet+DevopsResearch&Assessment)
DEVOPS – disclaimer
“It’s not about the destination,
it’s about the journey” – Gene Kim
DevOps n’est pas une méthodologie.
Il s’agit de créer une culture dans laquelle
Dev et Ops collaborent étroitement et en confiance.
DEVOPS – une proposition de définition
L’approche DEVOPS a un objectif unique :
▪ aligner l'ensemble des acteurs et des compétences
du système d’information…
▪ … sur la seule qualité du produit fourni à
l'utilisateur final
Pour cela, la démarche DEVOPS passe par…
▪ l'engagement de l'ensemble des acteurs sur la
chaîne de production de valeur,
▪ dans une collaboration libre et sans contrainte
▪ et le souci d’une amélioration continue
▪ par le partage d'informations et de responsabilité
▪ et des outils et méthodes communes
▪ en vue d'automatiser les actions
▪ et ainsi d’étendre au maximum l’autonomie des
différents acteurs en dehors de leur périmètre
propre
La démarche DEVOPS
L’approche DEVOPS
the Beal-Hedemark
golden square
Coût Temps
Qualité Satisfaction
Culture
Automation
Lean
Measure
Sharing
DEVOPS
les origines
DEVOPS – le mur de la confusion
Depuis toujours, DEV et OPS s’opposent à cause
d’objectifs antagonistes…
Les DEV recherchent :
▪ la rapidité de mise à disposition des nouvelles
fonctionnalités aux utilisateurs finaux
▪ culture du produit
Les OPS recherchent :
▪ la stabilité, la robustesse
▪ la maîtrise, la performance
▪ la sécurité
▪ l’industrialisation
▪ l’efficience économique
▪ culture du service
Mais il y a confusion : ces objectifs sont des
objectifs intermédiaires et non exclusifs !
“We don’t need an accurate document, we
need a shared understanding” – Jeff Patton
AGILE – au départ, des difficultés similaires…
PRATIQUES
▪ des équipes en silo
▪ des échanges sous forme « contractuelle »
client/fournisseur
▪ un « effet tunnel » systémique
▪ des hypothèses de travail amont qui contraignent
la réalisation
CONSTATS
▪ un projet mal maîtrisé (coûts, délais)
▪ des écarts de conformité du livrable avec le besoin
▪ l’apparition tardive des soucis rend les correctifs
très coûteux et douloureux
▪ à chaque étape, la pression du planning conduit à
accepter les approximations des étapes amont
▪ l’OPS, en bout de cycle, doit se faire le garant du
livrable le plus « dénaturé »
AGILE – le pragmatisme et le business…
PRATIQUES
▪ des cycles courts et itératifs
▪ des équipes resserrées incluant fonctionnels et
techniques
▪ « Do, learn, adapt ! »
▪ « less documentation is more communication »
▪ la construction commune et quotidienne des
fonctionnalités du produit
▪ des mises en production plus fréquentes
CONSTATS
▪ un projet mieux maîtrisé (coûts, délais)
▪ des ajustements plus rapides et plus fréquents
pour rester pertinent
▪ l’introduction de la notion de « fail fast »
▪ une responsabilité partagée entre fonctionnels et
techniques
▪ … mais l’OPS n’est toujours pas systématiquement
inclus dans la démarche
DEVOPS
Ops, the final frontier
▪ Les méthodes agiles accélèrent et fiabilisent les
livraisons des DEV.
▪ Les OPS et le déploiement sont perçus comme
l’ultime frein à accélérer le Time-to-Market
(TTM).
▪ La nécessité de faire sauter ce dernier goulot d’
étranglement devient flagrante.
SOFTWARE FACTORY – le time-to-market s’impose…
L’usine logicielle,
utilisée par les DEV,
nécessite le
savoir-faire des OPS :
▪ forts besoins en
optimisation
d’infrastructure
▪ forts besoins en
automatisation
« système »
SOFTWARE FACTORY – terrain de réconciliation ❤
Usine de Build
Build
Vérifier la
qualité
du code
Compiler
Récupérer les
dépendances
Déployer
Documenter
Exécuter les tests
Packager
Référentiel
binaires
Référentiel
de tâches
et anomalies Plateforme
de tests
Documentation
& Indicateurs
BuildGestionnaire
de sources
Build
local
Notifications
Serveur
d’intégration
continue
Les besoins en environnements de test explosent :
▪ organisation des équipes par domaine fonctionnel
(feature teams)
▪ automatisation des tests (fonctionnels,
performances, robustesse, conformité graphique,
multi-canal)
SOFTWARE FACTORY – infrastructure everywhere!
Le déploiement continu en Production de chaque
nouvelle fonctionnalité dès qu’elle est livrée
démultiplie les besoins dans le savoir-faire des OPS :
▪ pression de la vélocité
▪ architecture technique complexe (micro-services)
▪ modèles de déploiement complexes (blue/green,
canary testing)
▪ évolution perpétuelle de l’infrastructure technique
▪ environnements éphémères
▪ bacs à sable à la demande pour les équipes des
systèmes connectés
CONTINUOUS DELIVERY – warp speed factor 8!
“How long would it take your organization to deploy a
change that involves just one single line of code?”
- Poppendiek
L’OPS devient
un acteur indispensable
à la réussite
du projet de développement
DEVOPS – blue/green deployment
DEVOPS
is… / is not…
DEVOPS – is not…
5- “to be a devops, use the tool xxx…”
▪ DevOps n’est pas prioritairement une affaire d’outil.
▪ L’usage d’un outil fréquemment utilisé dans les
organisations DevOps n’est ni nécessaire, ni encore moins
suffisant pour faire du DevOps.
1- “One tool to rule them all”
▪ Le partage d’outils doit répondre à un besoin de
coopération et d’autonomie.
▪ Et non pas à un besoin d’industrialisation ou de respect des
standards.
2- “No-OPS”
▪ L’automatisation est un vecteur d’autonomisation des
acteurs et d’amélioration des opérations.
▪ Pas un moyen de se décharger de sa responsabilité.
3- “Every DEV has the root password”
▪ DevOps est un mouvement favorisant la coopération, pas le
remplacement des OPS par les DEV.
▪ Dans ce sens, certains DEV peuvent avoir besoin de root.
▪ Par nature, DevOps doit minimiser ce besoin.
4- “Every sysadmin should write code / every
DEV should rack servers”
▪ La coopération étroite ne veut pas dire la polyvalence de
tous.
▪ C’est, au contraire, reconnaître les forces et faiblesses de
chacun et en tirer le meilleur, collectivement.
DEVOPS – is…
7- “Fail fast”
L’erreur est une richesse d’expérience. Il faut l’accepter
comme une composante du mode opératoire, et expérimenter
au plus faible coût (et PDCA).
8- “Most valuable product”
Toute réalisation doit être itérative, pour accélérer l’arrivée
de la feedback loop. On doit chercher le plus petit élément de
réalisation qui apporte le maximum de valeur.
9- “In God we trust. Everything else, we test”
Toute réalisation n’est achevée que lorsque le test
garantissant la conformité de son fonctionnement est
associé.
10- “Less doc is more communication”
La documentation n’existe pas per se. Elle rendue inutile par
le partage des outils et méthodes, du même espace de travail
et les rituels de partage de connaissance (stand-up meeting,
peer-programming, demo)
11- “Everything fails all the time!” - Werner Vogels
Pannes et erreurs humaines sont inévitables. Par design, on
doit les circonscrire et mettre en place les contre-mesures
qui rendent ces pannes indolores.
1- “User-centric product”
La qualité et la pertinence du produit fourni à l’utilisateur final est la
seule chose qui importe.
2- “You build it, you run it!” - Werner Vogels
le DEV est (co-)responsable de ce qui arrive en Prod
(y-compris dans les astreintes).
3- “OPS as enablers, not gatekeepers”
- Lindsay Holmwood
Dans les domaines dont il est garant, l’OPS doit être
facilitateur par son savoir-faire et non-pas censeur.
4- “Measure everything” - Etsy
L’obsession de la mesure et de la traçabilité. Ce qui ne se
mesure pas n’est qu’affaire d’opinion.
5- “Plan, do, check, act (PDCA)”
La démarche d’amélioration continue, basée sur
l’expérimentation perpétuelle et la mesure du résultat qui en
ressort.
6- « Souriez, vous êtes filmés »
Par défaut, la modération n’existe pas. Elle n’intervient qu’à
postériori d’une douleur rencontrée. Pas d’over-engineering.
DEVOPS
knowing the path vs. walking the path
6- Augmentez le feedback des Ops
7- Mesurez votre succès à travers des KPIs
… synthétiques
8- Adaptez vos processus business à votre
vélocité de développement
9- Participez à la communauté
1- Commencez petit
… et faites de ce succès un hérault
2- Concentrez-vous sur la culture
… et pas sur les outils
3- Investissez sur les outils qui créent de la
visibilité en temps réel
… et l’intégration poussée dans l’usage de ces
outils
4- Déployez des technologies
d’automatisation
… et ouvrez-en l’usage aux populations du projet
5- Augmentez votre vitesse de déploiement
… et faites-en un KPI du projet
DEVOPS – 9 bonnes pratiques à mettre en œuvre…
TRS – le Taux de Rendement Synthétique
Ponctualité des Mises
en Production
▪ P1 - Respect des dates
de MEP
▪ P2 - Cadence des MEP
par rapport aux
sprints
▪ P3 - Profondeur des
décalages de date de
livraison
Taux de
Charge
TRG
Taux de
Disponibilité
Taux de
Performance
Taux de
Qualité
TRS
Disponibilité de la
plateforme à chaque
étape
▪ D1 - Rapidité de mise
à dispo. des
environnements
▪ D2 - Dispo. des
environnements
Exigences non
fonctionnelles
▪ Q1 - Qualité du code
▪ Q2 - Préparation de la
MEP
Expérience utilisateur
▪ Q3 - performance
applicative ressentie
par l’utilisateur 
▪ Q4 - Incidents suite à
MEP
Taux de
Disponibilité
Taux de
Performance
Taux de
Qualité
Utilisation efficiente
des ressources
▪ C1 - Taux d’utilisation
des ressources /
plateformes
LE TAUX DE RENDEMENT SYNTHÉTIQUE
▪ La mesure aide à fédérer et à faire adhérer
▪ Un moyen pratique d’établir un dialogue
▪ Le TRS permet d’aller vite à l’essentiel.
▪ Cultiver un état d’esprit collaboratif.
▪ L’essayer c’est l’adopter !
TRS – quels enseignements ?
6- Augmentez le feedback des Ops
7- Mesurez votre succès à travers des KPIs
… synthétiques
8- Adaptez vos processus business à votre
vélocité de développement
9- Participez à la communauté
1- Commencez petit
… et faites de ce succès un hérault
2- Concentrez-vous sur la culture
… et pas sur les outils
3- Investissez sur les outils qui créent de la
visibilité en temps réel
… et l’intégration poussée dans l’usage de ces
outils
4- Déployez des technologies
d’automatisation
… et ouvrez-en l’usage aux populations du projet
5- Augmentez votre vitesse de déploiement
… et faites-en un KPI du projet
DEVOPS – 9 bonnes pratiques à mettre en œuvre…
Les nouvelles formes de collaboration – Build / ship / run
DEV OPS
Ephemeral
Envs
Tools – Periodic table of DevOps tools
Tools – Continuous Delivery maturity matrix
Roadmap partagée et adaptative
Utiliser un outil de project mgmt unique (Jira) :
▪ workflow peu contraignant
▪ workflow facile à faire évoluer
Documentation en maintenance collaborative
▪ Rendre la documentation accessible à tous.
▪ Centraliser la doc dans un unique référentiel (Confluence).
▪ Permettre une maintenance collaborative avec validation
croisée (pull requests)
▪ Documentation comme vecteur de maîtrise vs. vecteur de
références
Specs as tests
Décrire les fonctionnalités qui, une fois compilées,
servent :
▪ de tests unitaires (Cucumber)
▪ ou de tests d’acceptance (FitNesse)
Souriez, vous êtes filmés
Mettre en place une métrologie accessible à tous sur l’
évolution des docs et des specs :
▪ vélocité d’évolution
▪ qualité des revues
▪ nombre d’allers-retours
Plan – Quelques pistes de mise en œuvre
DEV OPS
Poste de dev. disponible on-demand
Utiliser un outil de déploiement automatisé pour
configurer le poste de DEV (Ansible, Vagrant, Packer) :
▪ code disponible sur un dépôt partagé
▪ code adaptable à des contextes projets
▪ à l’échelle d’une équipe / d’un projet / de l’entreprise
Peer-review
Permettre une validation croisée (pull requests) entre
DEV, mais aussi entre DEV et OPS.
Dépôts de code communautaires
Utiliser des dépôts centralisés :
▪ fonctionnalités de collaboration sociale (Github, Gitlab,
BitBucket)
▪ gouvernance de type community management
▪ réemploi de code comme stratégie d’entreprise.
Lazy-coupled services
Permettre une évolution dissociée de différentes
applications / composants.
Test development kit
cf. rubrique test
Code – Quelques pistes de mise en œuvre
DEV OPS
Envs éphémères on-demand
Pouvoir paralléliser les builds et les tests :
▪ envs. on-demand (Infra as Code)
▪ architecture technique iso prod
▪ jeu de données de test as a service
Orchestration as Code
Décrire le workflow de build et de tests par
programmation (Jenkins Job DSL, Gitlab CI)
Performance des tests
Optimiser au maximum le temps de passage
end-to-end des tests.
▪ mise à dispo de l’env. de test
▪ passage des tests (tests automatisés)
▪ restitution consolidée des résultats
Test development kit
Fournir un jeu de tests (jeu de données compris) pour
tout code communautaire :
▪ tests automatisés
▪ jeu de données de test
▪ code de provisionning d’env. de test
▪ code de provisionning de workflow de test
Build / test – Quelques pistes de mise en œuvre
DEV OPS
Test like an Ops
Embarquer les tests liés au run :
▪ tests de fail-over / recovery / clustering
▪ tests de restauration de données
▪ tests de rollback
▪ tests de performance (nominal, aux limites, endurance)
▪ tests d’upscaling / outscaling
▪ tests d’accès / de sécurité
▪ tests de débordement
Page d’autodiagnostic
Inclure des tests de base au sein de l’applicatif
▪ test d’accès R/W aux données / aux logs (DB et FS)
▪ test de connexion aux composants techniques / applis
tierces
▪ test de load-balancing
▪ identification des serveurs portant les composants testés
▪ affichage de la configuration embarquée
Smoke tests
Jouer un scénario fonctionnel minimal avant et après
chaque opération en production
Test – Quelques pistes de mise en œuvre
DEV OPS
Release on demand
Autonomiser les acteurs du projet sur les opérations
techniques :
▪ configuration partagée et collaborative (CMDB on git)
▪ envs. on-demand (Infra as Code)
▪ déploiements automatisés
In God we trust. Everything else, we test
Tracer et tester l’état de la plateforme avant et après
chaque release/deploiement.
Full stack release management
Versionner et tracer tous les éléments mis en œuvre
dans une release :
▪ application
▪ données
▪ code de déploiement
▪ documentation et specs
▪ tests
▪ infrastructure (immutable infrastructure)
Release / deploy – Quelques pistes de mise en œuvre
DEV OPS
Self-service
Autonomiser les acteurs du projet sur les opérations
techniques :
▪ automatiser les tâches les plus courantes
▪ outil d’orchestration (Jenkins)
Ops As a Service… on demand
Packager et fournir les activités des administrateurs sur
un projet comme des services clé-en-main.
In God we trust. Everything else, we test
Inclure le provisionning et la configuration de la
métrologie avec chaque tâche de déploiement.
Partager les retours d’expérience
Rendre les post-mortem publics (fail con’).
Exposer les bonnes pratiques / les succès locaux.
Supervision collaborative
Partager la maintenance et le suivi de la supervision :
▪ outil accessible par tous les acteurs du projet
▪ capacités techniques et applicatives, voire projet
▪ maintenance collaborative avec validation croisée
▪ déploiement et maintenance as code : tests
Operate / monitor – Quelques pistes de mise en œuvre
DEV OPS
What’s next?
Questions ?

Contenu connexe

Tendances

Rapport de stage d’initiation
Rapport de stage d’initiationRapport de stage d’initiation
Rapport de stage d’initiation
GBO
 
Rapport de Mémoire Master Recherche
Rapport de Mémoire Master RechercheRapport de Mémoire Master Recherche
Rapport de Mémoire Master Recherche
Rouâa Ben Hammouda
 
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
FAO
 
Management d'intégration du projet
Management d'intégration du projetManagement d'intégration du projet
Management d'intégration du projet
younes elhaiba
 
Gestion de chantier ct btp_def 18-10-13
Gestion de chantier   ct btp_def 18-10-13Gestion de chantier   ct btp_def 18-10-13
Gestion de chantier ct btp_def 18-10-13
OURAHOU Mohamed
 
Pfe psi gribiss bouchta
Pfe psi gribiss bouchtaPfe psi gribiss bouchta
Pfe psi gribiss bouchta
GRIBISS BOUCHTA
 
FIDIC 2017 Yellow and Silver in EPC and PPP Contracts
FIDIC 2017 Yellow and Silver in EPC and PPP ContractsFIDIC 2017 Yellow and Silver in EPC and PPP Contracts
FIDIC 2017 Yellow and Silver in EPC and PPP Contracts
Loay Ghazaleh MBA, BSc Civil Eng.
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
YounessLaaouane
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
agnes_crepet
 
Modele rapport pfe esprit
Modele rapport pfe  espritModele rapport pfe  esprit
Modele rapport pfe espritAmine Chahed
 
gestion de projet
gestion de projetgestion de projet
gestion de projet
Wajdi kanzali
 
E-commerce Use case NFE102
E-commerce Use case NFE102E-commerce Use case NFE102
E-commerce Use case NFE102MRamo2s
 
Presentation stage Tunisie Telecom
Presentation stage Tunisie TelecomPresentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
litayem bechir
 
Pour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en InformatiquePour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en Informatique
Lilia Sfaxi
 
Gestion d'un projet de construction - Copy.pptx
Gestion d'un projet de construction - Copy.pptxGestion d'un projet de construction - Copy.pptx
Gestion d'un projet de construction - Copy.pptx
ofciahasni
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
COMPETENSIS
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Gedeon AGOTSI
 
Tout sur le ciment
Tout sur le cimentTout sur le ciment
Tout sur le ciment
Kouwelton Koné
 
Rapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUTRapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUT
Karim Souabni
 

Tendances (20)

Rapport de stage d’initiation
Rapport de stage d’initiationRapport de stage d’initiation
Rapport de stage d’initiation
 
Rapport de Mémoire Master Recherche
Rapport de Mémoire Master RechercheRapport de Mémoire Master Recherche
Rapport de Mémoire Master Recherche
 
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
5.2 - Contraintes rencontrées, solutions apportées, leçons tirées et recomman...
 
Management d'intégration du projet
Management d'intégration du projetManagement d'intégration du projet
Management d'intégration du projet
 
Gestion de chantier ct btp_def 18-10-13
Gestion de chantier   ct btp_def 18-10-13Gestion de chantier   ct btp_def 18-10-13
Gestion de chantier ct btp_def 18-10-13
 
Pfe psi gribiss bouchta
Pfe psi gribiss bouchtaPfe psi gribiss bouchta
Pfe psi gribiss bouchta
 
FIDIC 2017 Yellow and Silver in EPC and PPP Contracts
FIDIC 2017 Yellow and Silver in EPC and PPP ContractsFIDIC 2017 Yellow and Silver in EPC and PPP Contracts
FIDIC 2017 Yellow and Silver in EPC and PPP Contracts
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
Modele rapport pfe esprit
Modele rapport pfe  espritModele rapport pfe  esprit
Modele rapport pfe esprit
 
gestion de projet
gestion de projetgestion de projet
gestion de projet
 
E-commerce Use case NFE102
E-commerce Use case NFE102E-commerce Use case NFE102
E-commerce Use case NFE102
 
Presentation stage Tunisie Telecom
Presentation stage Tunisie TelecomPresentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
 
Pour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en InformatiquePour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en Informatique
 
Gestion d'un projet de construction - Copy.pptx
Gestion d'un projet de construction - Copy.pptxGestion d'un projet de construction - Copy.pptx
Gestion d'un projet de construction - Copy.pptx
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
 
Tout sur le ciment
Tout sur le cimentTout sur le ciment
Tout sur le ciment
 
Rapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUTRapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUT
 

Similaire à Devops, un tour d'horizon - Eutelsat 2018

Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
agnes_crepet
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
Radoine Douhou
 
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS FormationSéminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
ORSYS
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
Romain Chalumeau
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisJason De Oliveira
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
Adrien Blind
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequences
Stéphane Di Cioccio
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgile Toulouse
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?Goood!
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
Microsoft
 
2009 scrum&xp
2009 scrum&xp2009 scrum&xp
2009 scrum&xpdecsdeco
 
devops-ruche.pptx.pdf
devops-ruche.pptx.pdfdevops-ruche.pptx.pdf
devops-ruche.pptx.pdf
François Berthault
 
DU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLABDU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLAB
TREEPTIK
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
Jacky Galicher
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
Jacky Galicher
 
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
Objectif Libre
 
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetiteGab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
AZUG FR
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020
NimeOps
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011
Jean-Marc Fontaine
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
Pyxis Technologies
 

Similaire à Devops, un tour d'horizon - Eutelsat 2018 (20)

Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
 
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS FormationSéminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
Séminaire DEVOPS, DÉMARCHE ET MISE EN ŒUVRE - ORSYS Formation
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequences
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
 
2009 scrum&xp
2009 scrum&xp2009 scrum&xp
2009 scrum&xp
 
devops-ruche.pptx.pdf
devops-ruche.pptx.pdfdevops-ruche.pptx.pdf
devops-ruche.pptx.pdf
 
DU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLABDU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLAB
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
 
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
20151118 Retour d'Expérience : déploiement Cloud OpenStack chez un opérateur
 
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetiteGab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
Gab17 lyon-rex build dev ops sur une infra iaas-paas multisite-by-matthieupetite
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
 

Plus de Ludovic Piot

[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
Ludovic Piot
 
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
Ludovic Piot
 
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
Ludovic Piot
 
ClusterEurope2018 - Bootcamp Kubernetes - présentation
ClusterEurope2018 - Bootcamp Kubernetes - présentationClusterEurope2018 - Bootcamp Kubernetes - présentation
ClusterEurope2018 - Bootcamp Kubernetes - présentation
Ludovic Piot
 
A quick comparison of managed kubernetes services at public cloud providers'
A quick comparison of managed kubernetes services at public cloud providers'A quick comparison of managed kubernetes services at public cloud providers'
A quick comparison of managed kubernetes services at public cloud providers'
Ludovic Piot
 
CloudExpo Europe 2017 - DevOps entre client et fournisseur
CloudExpo Europe 2017 - DevOps entre client et fournisseurCloudExpo Europe 2017 - DevOps entre client et fournisseur
CloudExpo Europe 2017 - DevOps entre client et fournisseur
Ludovic Piot
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
Ludovic Piot
 
Oxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigDataOxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigData
Ludovic Piot
 
Oxalide Workshop #5 - Docker avancé & Kubernetes
Oxalide Workshop #5 - Docker avancé & KubernetesOxalide Workshop #5 - Docker avancé & Kubernetes
Oxalide Workshop #5 - Docker avancé & Kubernetes
Ludovic Piot
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performance
Ludovic Piot
 
Cloud hybridation leveraging on Docker 1.12
Cloud hybridation leveraging on Docker 1.12Cloud hybridation leveraging on Docker 1.12
Cloud hybridation leveraging on Docker 1.12
Ludovic Piot
 
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassinOxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
Ludovic Piot
 
Oxalide Workshop #3 - Elasticearch, an overview
Oxalide Workshop #3 - Elasticearch, an overviewOxalide Workshop #3 - Elasticearch, an overview
Oxalide Workshop #3 - Elasticearch, an overview
Ludovic Piot
 
Docker meetup - PaaS interoperability
Docker meetup - PaaS interoperabilityDocker meetup - PaaS interoperability
Docker meetup - PaaS interoperability
Ludovic Piot
 
PerfUG 3 - perfs système
PerfUG 3 - perfs systèmePerfUG 3 - perfs système
PerfUG 3 - perfs système
Ludovic Piot
 

Plus de Ludovic Piot (15)

[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
[Capitole du Libre] #serverless -  mettez-le en oeuvre dans votre entreprise...
 
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
 
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
DevoxxFR 2018 #serverless - Mettez-le en œuvre dans votre entreprise et arriv...
 
ClusterEurope2018 - Bootcamp Kubernetes - présentation
ClusterEurope2018 - Bootcamp Kubernetes - présentationClusterEurope2018 - Bootcamp Kubernetes - présentation
ClusterEurope2018 - Bootcamp Kubernetes - présentation
 
A quick comparison of managed kubernetes services at public cloud providers'
A quick comparison of managed kubernetes services at public cloud providers'A quick comparison of managed kubernetes services at public cloud providers'
A quick comparison of managed kubernetes services at public cloud providers'
 
CloudExpo Europe 2017 - DevOps entre client et fournisseur
CloudExpo Europe 2017 - DevOps entre client et fournisseurCloudExpo Europe 2017 - DevOps entre client et fournisseur
CloudExpo Europe 2017 - DevOps entre client et fournisseur
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
 
Oxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigDataOxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigData
 
Oxalide Workshop #5 - Docker avancé & Kubernetes
Oxalide Workshop #5 - Docker avancé & KubernetesOxalide Workshop #5 - Docker avancé & Kubernetes
Oxalide Workshop #5 - Docker avancé & Kubernetes
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performance
 
Cloud hybridation leveraging on Docker 1.12
Cloud hybridation leveraging on Docker 1.12Cloud hybridation leveraging on Docker 1.12
Cloud hybridation leveraging on Docker 1.12
 
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassinOxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
 
Oxalide Workshop #3 - Elasticearch, an overview
Oxalide Workshop #3 - Elasticearch, an overviewOxalide Workshop #3 - Elasticearch, an overview
Oxalide Workshop #3 - Elasticearch, an overview
 
Docker meetup - PaaS interoperability
Docker meetup - PaaS interoperabilityDocker meetup - PaaS interoperability
Docker meetup - PaaS interoperability
 
PerfUG 3 - perfs système
PerfUG 3 - perfs systèmePerfUG 3 - perfs système
PerfUG 3 - perfs système
 

Dernier

Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
UNITECBordeaux
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
Université de Franche-Comté
 
Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
abderrahimbourimi
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
Horgix
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
OCTO Technology
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Laurent Speyser
 

Dernier (6)

Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
 
Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
 

Devops, un tour d'horizon - Eutelsat 2018

  • 1. DevOps @ Eutelsat – 28-juin DEVOPS UN TOUR D’HORIZON
  • 3. Agenda UNE TENTATIVE DE DÉFINITION ▪ Pourquoi un tel engouement ? ▪ Disclaimer ▪ Une proposition de définition LES ORIGINES ▪ le mur de la confusion ▪ le mouvement agile : exemple à suivre ▪ le mur de la confusion OPS, THE FINAL FRONTIER ▪ la software factory : terrain de réconciliation KNOWING THE PATH VS. WALKING THE PATH ▪ DevOps is... / is not… ▪ TRS ▪ Tools ▪ Pistes de mise en œuvre
  • 5. DEVOPS – pourquoi un tel engouement ? Source:StateofDevOpsreport2016-2017 (Puppet+DevopsResearch&Assessment)
  • 6. DEVOPS – pourquoi un tel engouement ? Source:StateofDevOpsreport2016 (Puppet+DevopsResearch&Assessment)
  • 7. DEVOPS – disclaimer “It’s not about the destination, it’s about the journey” – Gene Kim DevOps n’est pas une méthodologie. Il s’agit de créer une culture dans laquelle Dev et Ops collaborent étroitement et en confiance.
  • 8. DEVOPS – une proposition de définition L’approche DEVOPS a un objectif unique : ▪ aligner l'ensemble des acteurs et des compétences du système d’information… ▪ … sur la seule qualité du produit fourni à l'utilisateur final Pour cela, la démarche DEVOPS passe par… ▪ l'engagement de l'ensemble des acteurs sur la chaîne de production de valeur, ▪ dans une collaboration libre et sans contrainte ▪ et le souci d’une amélioration continue ▪ par le partage d'informations et de responsabilité ▪ et des outils et méthodes communes ▪ en vue d'automatiser les actions ▪ et ainsi d’étendre au maximum l’autonomie des différents acteurs en dehors de leur périmètre propre La démarche DEVOPS L’approche DEVOPS the Beal-Hedemark golden square Coût Temps Qualité Satisfaction Culture Automation Lean Measure Sharing
  • 10. DEVOPS – le mur de la confusion Depuis toujours, DEV et OPS s’opposent à cause d’objectifs antagonistes… Les DEV recherchent : ▪ la rapidité de mise à disposition des nouvelles fonctionnalités aux utilisateurs finaux ▪ culture du produit Les OPS recherchent : ▪ la stabilité, la robustesse ▪ la maîtrise, la performance ▪ la sécurité ▪ l’industrialisation ▪ l’efficience économique ▪ culture du service Mais il y a confusion : ces objectifs sont des objectifs intermédiaires et non exclusifs !
  • 11. “We don’t need an accurate document, we need a shared understanding” – Jeff Patton
  • 12. AGILE – au départ, des difficultés similaires… PRATIQUES ▪ des équipes en silo ▪ des échanges sous forme « contractuelle » client/fournisseur ▪ un « effet tunnel » systémique ▪ des hypothèses de travail amont qui contraignent la réalisation CONSTATS ▪ un projet mal maîtrisé (coûts, délais) ▪ des écarts de conformité du livrable avec le besoin ▪ l’apparition tardive des soucis rend les correctifs très coûteux et douloureux ▪ à chaque étape, la pression du planning conduit à accepter les approximations des étapes amont ▪ l’OPS, en bout de cycle, doit se faire le garant du livrable le plus « dénaturé »
  • 13. AGILE – le pragmatisme et le business… PRATIQUES ▪ des cycles courts et itératifs ▪ des équipes resserrées incluant fonctionnels et techniques ▪ « Do, learn, adapt ! » ▪ « less documentation is more communication » ▪ la construction commune et quotidienne des fonctionnalités du produit ▪ des mises en production plus fréquentes CONSTATS ▪ un projet mieux maîtrisé (coûts, délais) ▪ des ajustements plus rapides et plus fréquents pour rester pertinent ▪ l’introduction de la notion de « fail fast » ▪ une responsabilité partagée entre fonctionnels et techniques ▪ … mais l’OPS n’est toujours pas systématiquement inclus dans la démarche
  • 15. ▪ Les méthodes agiles accélèrent et fiabilisent les livraisons des DEV. ▪ Les OPS et le déploiement sont perçus comme l’ultime frein à accélérer le Time-to-Market (TTM). ▪ La nécessité de faire sauter ce dernier goulot d’ étranglement devient flagrante. SOFTWARE FACTORY – le time-to-market s’impose…
  • 16. L’usine logicielle, utilisée par les DEV, nécessite le savoir-faire des OPS : ▪ forts besoins en optimisation d’infrastructure ▪ forts besoins en automatisation « système » SOFTWARE FACTORY – terrain de réconciliation ❤ Usine de Build Build Vérifier la qualité du code Compiler Récupérer les dépendances Déployer Documenter Exécuter les tests Packager Référentiel binaires Référentiel de tâches et anomalies Plateforme de tests Documentation & Indicateurs BuildGestionnaire de sources Build local Notifications Serveur d’intégration continue
  • 17. Les besoins en environnements de test explosent : ▪ organisation des équipes par domaine fonctionnel (feature teams) ▪ automatisation des tests (fonctionnels, performances, robustesse, conformité graphique, multi-canal) SOFTWARE FACTORY – infrastructure everywhere!
  • 18. Le déploiement continu en Production de chaque nouvelle fonctionnalité dès qu’elle est livrée démultiplie les besoins dans le savoir-faire des OPS : ▪ pression de la vélocité ▪ architecture technique complexe (micro-services) ▪ modèles de déploiement complexes (blue/green, canary testing) ▪ évolution perpétuelle de l’infrastructure technique ▪ environnements éphémères ▪ bacs à sable à la demande pour les équipes des systèmes connectés CONTINUOUS DELIVERY – warp speed factor 8! “How long would it take your organization to deploy a change that involves just one single line of code?” - Poppendiek L’OPS devient un acteur indispensable à la réussite du projet de développement
  • 19. DEVOPS – blue/green deployment
  • 21. DEVOPS – is not… 5- “to be a devops, use the tool xxx…” ▪ DevOps n’est pas prioritairement une affaire d’outil. ▪ L’usage d’un outil fréquemment utilisé dans les organisations DevOps n’est ni nécessaire, ni encore moins suffisant pour faire du DevOps. 1- “One tool to rule them all” ▪ Le partage d’outils doit répondre à un besoin de coopération et d’autonomie. ▪ Et non pas à un besoin d’industrialisation ou de respect des standards. 2- “No-OPS” ▪ L’automatisation est un vecteur d’autonomisation des acteurs et d’amélioration des opérations. ▪ Pas un moyen de se décharger de sa responsabilité. 3- “Every DEV has the root password” ▪ DevOps est un mouvement favorisant la coopération, pas le remplacement des OPS par les DEV. ▪ Dans ce sens, certains DEV peuvent avoir besoin de root. ▪ Par nature, DevOps doit minimiser ce besoin. 4- “Every sysadmin should write code / every DEV should rack servers” ▪ La coopération étroite ne veut pas dire la polyvalence de tous. ▪ C’est, au contraire, reconnaître les forces et faiblesses de chacun et en tirer le meilleur, collectivement.
  • 22. DEVOPS – is… 7- “Fail fast” L’erreur est une richesse d’expérience. Il faut l’accepter comme une composante du mode opératoire, et expérimenter au plus faible coût (et PDCA). 8- “Most valuable product” Toute réalisation doit être itérative, pour accélérer l’arrivée de la feedback loop. On doit chercher le plus petit élément de réalisation qui apporte le maximum de valeur. 9- “In God we trust. Everything else, we test” Toute réalisation n’est achevée que lorsque le test garantissant la conformité de son fonctionnement est associé. 10- “Less doc is more communication” La documentation n’existe pas per se. Elle rendue inutile par le partage des outils et méthodes, du même espace de travail et les rituels de partage de connaissance (stand-up meeting, peer-programming, demo) 11- “Everything fails all the time!” - Werner Vogels Pannes et erreurs humaines sont inévitables. Par design, on doit les circonscrire et mettre en place les contre-mesures qui rendent ces pannes indolores. 1- “User-centric product” La qualité et la pertinence du produit fourni à l’utilisateur final est la seule chose qui importe. 2- “You build it, you run it!” - Werner Vogels le DEV est (co-)responsable de ce qui arrive en Prod (y-compris dans les astreintes). 3- “OPS as enablers, not gatekeepers” - Lindsay Holmwood Dans les domaines dont il est garant, l’OPS doit être facilitateur par son savoir-faire et non-pas censeur. 4- “Measure everything” - Etsy L’obsession de la mesure et de la traçabilité. Ce qui ne se mesure pas n’est qu’affaire d’opinion. 5- “Plan, do, check, act (PDCA)” La démarche d’amélioration continue, basée sur l’expérimentation perpétuelle et la mesure du résultat qui en ressort. 6- « Souriez, vous êtes filmés » Par défaut, la modération n’existe pas. Elle n’intervient qu’à postériori d’une douleur rencontrée. Pas d’over-engineering.
  • 23. DEVOPS knowing the path vs. walking the path
  • 24. 6- Augmentez le feedback des Ops 7- Mesurez votre succès à travers des KPIs … synthétiques 8- Adaptez vos processus business à votre vélocité de développement 9- Participez à la communauté 1- Commencez petit … et faites de ce succès un hérault 2- Concentrez-vous sur la culture … et pas sur les outils 3- Investissez sur les outils qui créent de la visibilité en temps réel … et l’intégration poussée dans l’usage de ces outils 4- Déployez des technologies d’automatisation … et ouvrez-en l’usage aux populations du projet 5- Augmentez votre vitesse de déploiement … et faites-en un KPI du projet DEVOPS – 9 bonnes pratiques à mettre en œuvre…
  • 25. TRS – le Taux de Rendement Synthétique Ponctualité des Mises en Production ▪ P1 - Respect des dates de MEP ▪ P2 - Cadence des MEP par rapport aux sprints ▪ P3 - Profondeur des décalages de date de livraison Taux de Charge TRG Taux de Disponibilité Taux de Performance Taux de Qualité TRS Disponibilité de la plateforme à chaque étape ▪ D1 - Rapidité de mise à dispo. des environnements ▪ D2 - Dispo. des environnements Exigences non fonctionnelles ▪ Q1 - Qualité du code ▪ Q2 - Préparation de la MEP Expérience utilisateur ▪ Q3 - performance applicative ressentie par l’utilisateur  ▪ Q4 - Incidents suite à MEP Taux de Disponibilité Taux de Performance Taux de Qualité Utilisation efficiente des ressources ▪ C1 - Taux d’utilisation des ressources / plateformes
  • 26. LE TAUX DE RENDEMENT SYNTHÉTIQUE ▪ La mesure aide à fédérer et à faire adhérer ▪ Un moyen pratique d’établir un dialogue ▪ Le TRS permet d’aller vite à l’essentiel. ▪ Cultiver un état d’esprit collaboratif. ▪ L’essayer c’est l’adopter ! TRS – quels enseignements ?
  • 27. 6- Augmentez le feedback des Ops 7- Mesurez votre succès à travers des KPIs … synthétiques 8- Adaptez vos processus business à votre vélocité de développement 9- Participez à la communauté 1- Commencez petit … et faites de ce succès un hérault 2- Concentrez-vous sur la culture … et pas sur les outils 3- Investissez sur les outils qui créent de la visibilité en temps réel … et l’intégration poussée dans l’usage de ces outils 4- Déployez des technologies d’automatisation … et ouvrez-en l’usage aux populations du projet 5- Augmentez votre vitesse de déploiement … et faites-en un KPI du projet DEVOPS – 9 bonnes pratiques à mettre en œuvre…
  • 28. Les nouvelles formes de collaboration – Build / ship / run DEV OPS Ephemeral Envs
  • 29. Tools – Periodic table of DevOps tools
  • 30. Tools – Continuous Delivery maturity matrix
  • 31. Roadmap partagée et adaptative Utiliser un outil de project mgmt unique (Jira) : ▪ workflow peu contraignant ▪ workflow facile à faire évoluer Documentation en maintenance collaborative ▪ Rendre la documentation accessible à tous. ▪ Centraliser la doc dans un unique référentiel (Confluence). ▪ Permettre une maintenance collaborative avec validation croisée (pull requests) ▪ Documentation comme vecteur de maîtrise vs. vecteur de références Specs as tests Décrire les fonctionnalités qui, une fois compilées, servent : ▪ de tests unitaires (Cucumber) ▪ ou de tests d’acceptance (FitNesse) Souriez, vous êtes filmés Mettre en place une métrologie accessible à tous sur l’ évolution des docs et des specs : ▪ vélocité d’évolution ▪ qualité des revues ▪ nombre d’allers-retours Plan – Quelques pistes de mise en œuvre DEV OPS
  • 32. Poste de dev. disponible on-demand Utiliser un outil de déploiement automatisé pour configurer le poste de DEV (Ansible, Vagrant, Packer) : ▪ code disponible sur un dépôt partagé ▪ code adaptable à des contextes projets ▪ à l’échelle d’une équipe / d’un projet / de l’entreprise Peer-review Permettre une validation croisée (pull requests) entre DEV, mais aussi entre DEV et OPS. Dépôts de code communautaires Utiliser des dépôts centralisés : ▪ fonctionnalités de collaboration sociale (Github, Gitlab, BitBucket) ▪ gouvernance de type community management ▪ réemploi de code comme stratégie d’entreprise. Lazy-coupled services Permettre une évolution dissociée de différentes applications / composants. Test development kit cf. rubrique test Code – Quelques pistes de mise en œuvre DEV OPS
  • 33. Envs éphémères on-demand Pouvoir paralléliser les builds et les tests : ▪ envs. on-demand (Infra as Code) ▪ architecture technique iso prod ▪ jeu de données de test as a service Orchestration as Code Décrire le workflow de build et de tests par programmation (Jenkins Job DSL, Gitlab CI) Performance des tests Optimiser au maximum le temps de passage end-to-end des tests. ▪ mise à dispo de l’env. de test ▪ passage des tests (tests automatisés) ▪ restitution consolidée des résultats Test development kit Fournir un jeu de tests (jeu de données compris) pour tout code communautaire : ▪ tests automatisés ▪ jeu de données de test ▪ code de provisionning d’env. de test ▪ code de provisionning de workflow de test Build / test – Quelques pistes de mise en œuvre DEV OPS
  • 34. Test like an Ops Embarquer les tests liés au run : ▪ tests de fail-over / recovery / clustering ▪ tests de restauration de données ▪ tests de rollback ▪ tests de performance (nominal, aux limites, endurance) ▪ tests d’upscaling / outscaling ▪ tests d’accès / de sécurité ▪ tests de débordement Page d’autodiagnostic Inclure des tests de base au sein de l’applicatif ▪ test d’accès R/W aux données / aux logs (DB et FS) ▪ test de connexion aux composants techniques / applis tierces ▪ test de load-balancing ▪ identification des serveurs portant les composants testés ▪ affichage de la configuration embarquée Smoke tests Jouer un scénario fonctionnel minimal avant et après chaque opération en production Test – Quelques pistes de mise en œuvre DEV OPS
  • 35. Release on demand Autonomiser les acteurs du projet sur les opérations techniques : ▪ configuration partagée et collaborative (CMDB on git) ▪ envs. on-demand (Infra as Code) ▪ déploiements automatisés In God we trust. Everything else, we test Tracer et tester l’état de la plateforme avant et après chaque release/deploiement. Full stack release management Versionner et tracer tous les éléments mis en œuvre dans une release : ▪ application ▪ données ▪ code de déploiement ▪ documentation et specs ▪ tests ▪ infrastructure (immutable infrastructure) Release / deploy – Quelques pistes de mise en œuvre DEV OPS
  • 36. Self-service Autonomiser les acteurs du projet sur les opérations techniques : ▪ automatiser les tâches les plus courantes ▪ outil d’orchestration (Jenkins) Ops As a Service… on demand Packager et fournir les activités des administrateurs sur un projet comme des services clé-en-main. In God we trust. Everything else, we test Inclure le provisionning et la configuration de la métrologie avec chaque tâche de déploiement. Partager les retours d’expérience Rendre les post-mortem publics (fail con’). Exposer les bonnes pratiques / les succès locaux. Supervision collaborative Partager la maintenance et le suivi de la supervision : ▪ outil accessible par tous les acteurs du projet ▪ capacités techniques et applicatives, voire projet ▪ maintenance collaborative avec validation croisée ▪ déploiement et maintenance as code : tests Operate / monitor – Quelques pistes de mise en œuvre DEV OPS