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

Docker
DockerDocker
Ansible presentation
Ansible presentationAnsible presentation
Ansible presentation
Suresh Kumar
 
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Edureka!
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
NAVER D2
 
Microservices, Containers and Docker
Microservices, Containers and DockerMicroservices, Containers and Docker
Microservices, Containers and Docker
Ioannis Papapanagiotou
 
DevOps Meetup ansible
DevOps Meetup   ansibleDevOps Meetup   ansible
DevOps Meetup ansible
sriram_rajan
 
kubernetes, pourquoi et comment
kubernetes, pourquoi et commentkubernetes, pourquoi et comment
kubernetes, pourquoi et comment
Jean-Baptiste Claramonte
 
Kubernetes
KubernetesKubernetes
Kubernetes
erialc_w
 
OpenStack Glance
OpenStack GlanceOpenStack Glance
OpenStack Glance
openstackstl
 
Gitlab CI : Integration et Déploiement Continue
Gitlab CI : Integration et Déploiement ContinueGitlab CI : Integration et Déploiement Continue
Gitlab CI : Integration et Déploiement Continue
Vincent Composieux
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
ssuserf8b8bd1
 
Docker Basics
Docker BasicsDocker Basics
Docker Basics
DuckDuckGo
 
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
Amazon Web Services Korea
 
[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용
NAVER D2
 
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
Edureka!
 
Terraform
TerraformTerraform
Terraform
Diego Pacheco
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
boulonvert
 
Tadx - Présentation Conteneurisation
Tadx -  Présentation ConteneurisationTadx -  Présentation Conteneurisation
Tadx - Présentation Conteneurisation
TADx
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
Amazon Web Services Korea
 
Road to Microservices
Road to MicroservicesRoad to Microservices
Road to Microservices
Salvatore Cordiano
 

Tendances (20)

Docker
DockerDocker
Docker
 
Ansible presentation
Ansible presentationAnsible presentation
Ansible presentation
 
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
 
Microservices, Containers and Docker
Microservices, Containers and DockerMicroservices, Containers and Docker
Microservices, Containers and Docker
 
DevOps Meetup ansible
DevOps Meetup   ansibleDevOps Meetup   ansible
DevOps Meetup ansible
 
kubernetes, pourquoi et comment
kubernetes, pourquoi et commentkubernetes, pourquoi et comment
kubernetes, pourquoi et comment
 
Kubernetes
KubernetesKubernetes
Kubernetes
 
OpenStack Glance
OpenStack GlanceOpenStack Glance
OpenStack Glance
 
Gitlab CI : Integration et Déploiement Continue
Gitlab CI : Integration et Déploiement ContinueGitlab CI : Integration et Déploiement Continue
Gitlab CI : Integration et Déploiement Continue
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
 
Docker Basics
Docker BasicsDocker Basics
Docker Basics
 
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중
 
[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용
 
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
What is Docker | Docker Tutorial for Beginners | Docker Container | DevOps To...
 
Terraform
TerraformTerraform
Terraform
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
Tadx - Présentation Conteneurisation
Tadx -  Présentation ConteneurisationTadx -  Présentation Conteneurisation
Tadx - Présentation Conteneurisation
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
 
Road to Microservices
Road to MicroservicesRoad to Microservices
Road to Microservices
 

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

COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU  SOUS WINDOWSCOURS D'ADMINISTRATION RESEAU  SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
AlbertSmithTambwe
 
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
 
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
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
OCTO Technology
 
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
 
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptxPRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
AlbertSmithTambwe
 
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
 

Dernier (9)

COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU  SOUS WINDOWSCOURS D'ADMINISTRATION RESEAU  SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
 
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)
 
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
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
 
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...
 
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptxPRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
 
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
 

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