Le 03/02/2021
DevOps
Introduction
1
Qui suis-je ?
CommercialChef de projet
Infra, Réseau (~Ops)Fan de scripting,
CTF et autres challenges
Ingénieur Chimiste Développeur puis Expert technique
Java, .net, Js, …
Architecte SOA
Architecte Logiciel
Architecte Cloud & DevOps enthousiaste
SCHMITT SébastienArchitecte Cloud
2
Plan du document
• La Stratégie DevOps
• Organisation
• Architecture
• Outillage
• Gouvernance
• REX
3
La stratégie DevOps
4
Définition• DevOps est la concaténation du mot anglais « development » (développement) et « operations »
(exploitation).
• DevOps est issu de conférences professionnelles (devopsdays.org)
• « DevOps est un ensemble de pratiques (une philosophie) multi-disciplinaires consacrées à l’étude dela construction, de la maintenance évolutive et de l’exploitation de systèmes informatiques qui doiventpouvoir être modifiés rapidement. » - Jez HUMBLE.
• Objectif : diminuer la durée comprise entre la demande de modification d’un service IT et sa mise enligne tout en améliorant la qualité des applications et en diminuant le coût.
5
Constat: fonctionnement en SILO
Développer une culture collaborative et améliorer la communication
Développement Agile DevOps
6
Préconisations• Plus petit, plus vite et plus souvent
• Modifier l’organisation autour d’équipes autonomes, multi compétentes en charge de l’ensemble ducycle de vie (modèle « build & run »)
• Architecture agile (modulaire)
NETFLIX (chiffres plus très à jours mais l’idée demeure) :
• 100 déploiements / jour
• Equipe co-localisée par application
• La plateforme démarre et arrête des instances en fonction de la charge ou pour compenser des incidents
• Les développeurs sont responsables du fonctionnement et peuvent être appelés à toute heure
7
1. Culture et organisation
8
Initialisation de la transformationculturelle et organisationnelle.Mise en place de l’agilité surl’équipe étendue
1- Fluidification
Équipes virtuelles responsable dubuild et de la gestion des incidentsen production. Compétences infra.et dev. délocalisées
2- Hybridation
Equipe pluridisciplinaire etresponsable« you build it, you run it »
3- Unification
DevOps Evangelist
Change Manager
Release manager
Architecte Automatisation
Ingénieur Sécurité
Nouveaux rôles
Change Management
9
Exemple d’organisation
Spotify a su créer une culture ouverte et flexible, basée sur l’autonomie,
source de motivation et propice à l’innovation.
10
• Les squads sont des équipes de 5 à 7 ingénieurs et d’un Product Owner
totalement autonomes comme si ensemble ils créaient une startup. On fait
en sorte que cette Squad soit pluridisciplinaire.
• Chaque Squad est autonome et peut utiliser la méthodologie agile ou
apparentée agile de son choix voire celle qui est la plus adaptée au besoin :
Scrum, kanban, Lean startup…..
Organisation en Squad
La Pizza team
11
• Dans chaque Squad, nous avons des compétences
équivalentes.
Rassembler 1 personne de chaque squad pour
créer un chapitre permet de s’aligner sur une
même vision/pratique commune.
• 1h / semaine entre chaque chapitre suffit souvent
pour avoir une meilleure vision globale et de ne pas
voir chaque Squad partir chacune dans leur coin …
Synchroniser les pratiques
Les chapitres
12
• Les tribus représentent plusieurs Squads (de
5 à 8) qui travaillent ensemble sur un même
thème global.
• Il est conseillé de ne pas dépasser des tribus
de 80 personnes afin de garder un
dimensionnement raisonnable.
Transversalité
Les tribus
13
• Les guildes rassemblent des personnes dans
l’ensemble de l’entreprise pour qu’elles puissent
régulièrement partager sur des sujets similaires afin
de s’aligner sur une même vision.
• Le participation est libre et ouverte.
Communautés d’intérêt spécifiques
Les guildes
14
• Formation : former les équipes grâce à des formations classiques, des workshop de partage…
• Hack day ou hack week : sessions pour développer quelque chose de différent qui pourrait apporter
un jour à l’entreprise.
• Adds-on : 20% du temps de chacun est consacré à s’améliorer soit 1 journée chaque semaine.
• Post-mortem : on se rassemble 1 journée complète pour partager sur un incident passé. Ce principe
se rapproche des 5 pourquoi qui permet d’aller chercher plus loin la source du problème.
Les pratiques recommandées
Amélioration continue
15
2. Design & Architecture modulaire
16
Web stg
Service
Browser app or embedded in native
JSONEvents & notifications
HTTP &Websockets
Service Service Business / Domain services
Service Service Service
SQL NoSQL Other
API
HTML & JS Engine
DOM Controllers
Client-side model
• L'architecture microservices est une approche de conception qui
consiste à diviser une application en un ensemble de petits services.
• Les microservices sont conçus autour de capacités métier, et dédiés à
une seule fonction.
• Vous pouvez utiliser différents frameworks ou langages de
programmation pour les écrire et les déployer indépendamment, en
tant que service unique ou en tant que groupe de services.
HTML & JS Engine
DOM Controllers
Client-side model Web stg
Service Layer
Channels Repositories RDBMS
Browser app or embedded in native
JSONEvents & notifications
HTTP &Websockets
CRUD
Architecture modulaire
17
Les architectures « cloud »Des services managés
permettent d’accélérer la mise
en place.
La containerisation garantit la
portabilité des solutions (cloud
privée, public, on-premise…)
Les approches « server-less »
prennent en charge de manière
performante des conteneurs.
CognitoUser Management
API GatewayRESTful API
CloudWatch LogsMicroservices Logging
Trust Advisorroles and policies
Database
Identity Token
1
2
3
4
56
docker containerMicroservices
BackOfficeFrontOffice
18
Stratégies de développement• Il existe de nombreux workflow de développement « Gitflow », « Simple Branching », …
• Il faut choisir celui qui correspond le mieux à votre équipe / votre besoin !
Gitflow le code de la branche master est le code qui est prêt pour passer en production.
Très intéressant quand on utilise toujours la dernière version du logiciel, mais qu’est-ce qui se passe quand on doit supporter plusieurs versions ?
19
• Simple branching est une pratique de développement dans laquelle tous
les développeurs « commit » leurs changements sur une seule branche
qui est « delivery-ready ».
• Cette pratique nécessite d’avoir une couverture complète de tests
unitaires automatisés et de les jouer à chaque commit. Dans cette
organisation, chaque version livrée en production est tagguée afin de
pouvoir au besoin la « patcher » sans avoir à intégrer les développements
de la branche principale.
• Le simple branching permet de limiter au maximum les « merge », et
oblige à utiliser la plupart des bonnes pratiques de développement, dont
le « feature flipping » en particulier.
« Simple Branching »
Stratégies de développement
20
Blue/green deployment- Permet à minima, d’effectuer des mises en
production de manière transparente
Stratégies de déploiement
Canary release- Tester de nouvelles fonctionnalités sur une petite
population cible avant ouverture complète
Feature toggle- Activation très rapide de nouvelles fonctionnalités
en Production
21
La notion de « test » s’invite
dès l’analyse du besoin et la
conception.
Le test ne sert plus
seulement à vérifier
l’absence d’anomalie mais
également à guider la
conception et les
développements de la
solution logicielle.
Stratégies de tests
22
Automatisation des tests
TU TU
Recette Recette
Cycle en V Mode DevOps
23
3. Outillage
24
La chaîne d’outils DevOps
25
Tableau périodique des outils DevOps
26
Intégration / Livraison / Déploiement continue
• Intégration continue : Build et TU automatisés pour détecter les erreurs au plus tôt
• Livraison continue : Déploiement pour recette, tests et validation manuels avant la prod
• Déploiement continue : Mise en production automatique
27
Monitoring
• Suivre les métriques et les logs permet de découvrir l'impact des performances de
l'application et de l'infrastructure sur l'expérience de l'utilisateur final.
• La supervision active et automatisée est de plus en plus importante, car les services doivent
aujourd'hui être disponibles 24h / 24 et la fréquence des mises à jour augmente sans cesse.
Watch
28
4. Gouvernance des équipes
29
Gouvernance• Choix stratégiques d’une entreprise
• Permet de coordonner l’ensemble des services pour être en accord avec la vision de l’entreprise.
Mesurer
Expérimenter PrioriserOn ne peut améliorer
que ce qu’on mesure !
30
REx
31
Retour d’expérienceTransformation DevOps d’une grand fabriquant de pneus Français
• 2012 : Première expérience Agile/DevOps Arrêt en 2013 car les managers n’étaient pas impliqués/moteurs
• Lancement en 2013 d’un plan de transformation sur 5 ans
• Découpage en 4 chantiers :
• Expérimentation sur une équipe avec un périmètre complet.
• Définition d’un catalogue standard et gestion en auto-provisionnement
• Reprise à leur charge de toute l’infra existante en 2 ans
• Refonte des équipes internes en Delivery Squads
Réussite de la transformation en 2018/2019
32
Expérimentation
From a continuous integration toolset to a continuous delivery platform with: release automation, infra provisioning,…
• One Integrated Team (People + process + tools)
• NFR = A function of the application
• Std catalog & Self provisonning
• Adaptive project life cycle
• Validation Based on risk Mngmt
• Release Train to go-live
33
Refonte des équipes
MODÈLE D’ORGANISATION DU TRAVAIL
SCRUM WATERFALL KANBAN
Attributs
STABLE DANS LE TEMPS AUTO-ORGANISÉE PLURIDISCIPLINAIRE MEMBRE DE L’ÉQUIPE DÉDIÉ CO-LOCALISÉ (AUTANT QUE
POSSIBLE)
34
Quizz DevOpsVoyons si vous avez suivi
Source : https://www.rudder.io/fr/blog/2015/08/25/quiz-expert-devops/
https://app.klaxoon.com/join/ZC8M6XZ
35
DevOps, c’est quoi ?
1. Une philosophie de travail pour les équipes IT.
2. Des outils pour les équipes dev et ops.
3. Une personne qui fait le lien entre les devs et les sysadmins.
36
Comment se former sur le sujet ?
1. Embaucher des consultants expert DevOps.
2. Appliquer des conseils d’internet au pied de la lettre sans se polluer l'esprit avec le contexte existant, les experts de la toile ont forcément raison !
3. Aller dans des conférences, partager son expérience, l’apprentissage et la communication c’est la base.
37
Pour faire passer les équipes au DevOps il faut
1. Enlever les barrières entre les équipes, faciliter la discussion et le partage de compétence transverses.
2. Solliciter un architecte DevOps permettant de mieux faire coopérer les équipes.
3. Constituer une équipe DevOps séparée des équipes actuelles, afin que chacun puisse faire son travail sans gêner les autres.
38
A quoi ça sert ?
1. Réduire les effectifs, les devs peuvent remplacer les ops et inversement, et donc réduire les coûts.
2. Suivre les tendances hype c'est important pour rester à la page, et dans un an on change.
3. Favoriser le partage de points de vue et de compétences entre les équipes permet de réduire les tensions, et de fournir des livrables plus proche des besoins, plus tôt.
39
Des serveurs sauvages apparaissent !
1. Pas de soucis, on a une image d'une ancienne machine, on la clone et on fait les modifs restantes avec le script à Didier.
2. Ils sont intégrés dans les process d’automatisation (provisioning, gestion de configuration, etc.) et... c'est tout c'est fini !
3. Il faut tout configurer à la main afin de mieux maîtriser les paramètres.
40
Il faut mettre en prod, comment ça se passe ?
1. Thierry push son commit, ça marche sur son poste, même si c’est pas à lui de s’occuper de la mise en prod, en plus on est Vendredi.
2. Thierry push son commit, les membres de l'équipe collaborent afin de valider correctement cette version avant qu'elle soit effectivement mise en prod.
3. Thierry push son commit dans Git, il y a tout un pipeline d’outils ContinuousDelivery, le Jenkins générera une nouvelle image Docker à publier direct dans le cloud...
41
Les principes DevOps sont "C.A.M.S.", ce qui signifie :
1. Create, Anticipate, Migrate, Simplify
2. Cloud, Ambition, Manual, Servers
3. Culture, Automation, Measurement, Sharing
42
DevOps : Key points
• C’est une culture d’entreprise
• Les managers doivent être moteurs
• Mais tout le monde est impliqué
• Il faut revoir la façon de concevoir/développer
• Les outils peuvent vous aider
• Tester le TDD, la conteneurisation (docker), le Cloud
43
Merci