Presentation DevOps : enjeux , objectifs, consequences

Introduction
Philosophie et Culture de la démarche
DEVOPS
Application DIGITALES

DEVOPS … par où commencer … ?
DevOOOpS Kesako ?
Synthèse / Explication des Processus DevOpS
Impacts sur les Structures Organisationnels
Modification des Périmètres et Responsabilités
Solutions techniques et Otimisations de l’existant

La Philosophie « DEVOPS »
« DevOpS est une approche qui met l'accent sur un développement rapide, à petite
échelle et itératif et sur un déploiement des applications qui permet de mieux répondre
aux besoins du client. Il est caractérisé par un revirement culturel dans lequel les
fonctions Développement et Opérations sont réunies en une seule équipe. »
Une Culture ,
Une approche agile sur l’ensemble de la chaine ,
Une nouvelle donne technique et humaine ,
Une implication forte de l’ensemble des équipes.

DEVOPS : une philosophie née de l’amélioration continue
« DevOpS » vient de la contraction entre « Development » et « Opérations » et S pour
« Support »
C’est dans les grands principes du Lean Management, et plus précisément dans
l’amélioration continue des processus, qu’apparaît le DevOpS.
Cette approche s’applique essentiellement au domaine du développement logiciel et prône
l’efficacité et la productivité au sein des équipes projet.
DevOpS intègre pleinement les rôles opérationnels traditionnellement dévolus à des
équipes dédiées et séparées des développeurs.
La démarche est focalisée sur l’idée que le temps de mise sur le d’une nouvelle offre pour
une entreprise doit être réduit de manière drastique (Time To Market).
Consiste à apporter de l’Agilité sur la chaine de bout en bout.

Les Axes essentiels pour la mise en Place du DEVOPS
La collaboration est essentielle. Création d’un environnement et une culture de collaboration et de
partage. La collaboration entre les membres des équipes ne pourra se faire sans l’investissement et
l’implication de la hiérarchie pour amener les personnes à suivre la même direction et à atteindre le même
objectif.
L’automatisation de bout en bout est essentielle pour créer des processus itératifs, fréquents,
réutilisables et fiables. Produire, Tester, Intégrer et Livrer plus rapidement des applications ou services
permet au métier de s’adapter plus vite et d’être plus performant. Le déploiement continu est une cible.
Un Revirement culturel ET une Collaboration des équipes
Un Outillage Automatisé (intégration, livraisons, déploiements, tests…)
Des Processus adaptés et adoptés
Les processus sont essentiels et permettent d’encadrer et sécuriser les environnements exploités.
Les Processus sont partagés, adoptés et compris par toutes les équipes.
On ne laisse pas les environnements Préprod , Prod en libre accès !

Synergie ITIL et DEVOPS
ITIL (IT Infrastructure Library) est une référence mondial des bonnes pratiques dédiées à l'industrie IT et
principalement utilisé pour la gestion de la production. C’est également un référentiel et un langage
commun pour les différentes équipes.
De premier abord, Planification, documentation, processus et vérifications demandées par ITIL semblent
être du côté opposé des DevOpS et Agile.
Les outils mis en place pour gérer les processus peuvent être lourds. Des tâches simples et courantes
comme redémarrer un service, modifier une planification, passer un correctif peuvent être complexes et
nécessiter des procédures formalisées et de multiples étapes de validation.
Il est possible d’automatiser et simplifier un certains nombre de tâches et de permettre une synergie
efficace de ces méthodes.
L’alignement des pratiques et l’agilification des processus
est l’essence de DevOpS.

Infrastructure As Code
Gestion de l’infrastructure par du Code
Même Cycle de livraison que l’applicatif
Provisioning automatique ou à la demande.
Déploiement continu
Mise en place d’une chaine automatisée.
de l’intégration à la production.
Réduction des erreurs humaines
Culture de Collaboration
Objectifs communs entre les équipes
Des Processus partagés et adoptés
Des équipes fonctionnelles décloisonnées.

Résumé des points Clés
Une nouvelle Culture et une Collaboration des équipes
Une Agilité sur l’ensemble de la chaine (infrastructure, développement, déploiement )
La satisfaction client avant tout !
Une Culture … Des Processus … Des Outils !

Les Processus du DEVOPS, l’industrialisation et
la cible de déploiement continu

Les Processus du DEVOPS
Quelques Chiffres (2013!)
LesFurets.com 1 déploiement par jour
Facebook 2 déploiements par jour
Flickr 10 déploiements par jour
Intercom 20 déploiements par jour
Etsy 50 à 60 déploiements par jour
HubSpot 300 déploiements par jour
Amazon 1 déploiement toutes les 11,6 secondes
Non atteignable sans les processus et outils adaptés !
.. Et vous .. ?
Le nombre de
déploiement par jour
n’est pas une fin en
soi, l’objectif est de
pouvoir livrer quand
on veut livrer !

Vision Synthétique
DEV OPS

Vision intégrée
Accélérer le Time To Market
Equilibrer vitesse, coût, qualité
et risque.
Réduire le temps de retour Client
1
2
3 4
5
6
Développements Agile
Cycles itératifs (Sprint)
Backlog produit
Intégration Continue
Construction package
Tests (unitaires, code…)
Déploiement en UAT/PPD
Même livrable
Tests (charge, perfs, intrusion..)
Déploiement en Production
Push button
Installation & Rollback automatisé
Surveillance continue
Monitoring & Supervisions
Détection des anomalies
Feedback Continu
Update du statut / préconisations
Retour à chaque étape
Amélioration Continue
Etablir une cible à atteindre
Mise en œuvre de Plan d’amélioration
Post implémentation review …

1 – Développement : Les Méthodologies Agiles
Méthodes utilisées par les DEV qui repose sur des cycles itératifs et adaptatifs (besoins évolutifs).
Permettent de pallier au traditionnel cycle en V ou tout doit être défini dès le début (besoins, planning …).
Préférence pour des équipes organisées par fonction (Features Teams).
Cycles de développement rapides qui apportent de nouvelles fonctions à la fin du cycle.
Valeurs Agiles (Manifeste):
L'équipe et la communication avant les outils et processus.
L'application avant la documentation.
La collaboration avant la négociation contractuelle.
L'acceptation du changement et la flexibilité avant la planification.
Quelques Méthodologies Agiles :
Scrum, Extreme Programing, Feature Driven Developpement, Kanban …
Des Bonnes Pratiques …
Gestion des évolutions
Fonctionnalités conçues pour être indépendantes
Livrable dès que c’est prêt
Découplage des fonctionnalités
Environnement de DEV
Chaque fonctionnalité sur une branche Feature dédiée
Environnement Quasi iso Production

Développement: Best Practises
Fonctionnalités conçues pour être indépendantes
Environnement iso Production (ou quasi)
Packaging et livraison de ce qui est prêt dès que c’est prêt
Chaque fonctionnalité sur une branche Feature dédiée
Complétude : tester ce que le programme doit et ne doir pas faire

Backlog Produit: Liste des éléments fonctionnels à implémenter classée par priorité
Sprint Backlog : Liste des éléments à embarquer dans un sprint (Pas de Changement pendant les Sprints)
Standup Meeting : Revue quotidienne sur l’avancement du Sprint avec les équipes
Burndown Chart : Suivi graphique de l’effort restant a faire pour finaliser le sprint.
Objectifs
Satisfaire le Client en livrant rapidement et régulièrement des fonctionnalités à VA
Livrer fréquemment un logiciel opérationnel avec des cycles courts ( < 1 mois )
Utilisateur et développeur travaillent ensemble
1 – Développement : Les Méthodologies Agiles : Focus SCRUM

L’intégration Continu
La Livraison Continu
Le déploiement Continu
T
E
S
T
S
C
O
N
T
I
N
U
S
Focus sur les tests
Les tests continus impliquent de
tester au plus tôt et en continu tout
au long du cycle de vie, ce qui permet
de réduire les coûts, de raccourcir les
phases de test et de disposer de
retours en continu sur la qualité. Ce
processus, appelé également shift-left
testing vise à intégrer les activités de
développement et de test pour que la
qualité soit incorporée aussi tôt que
possible dans le cycle de vie et non
pas repoussée à une phase ultérieure
S
U
R
V
E
I
L
L
A
N
C
E
C
O
N
T
I
N
U
E

Les Tests : Best Practises
Indépendance : le développeur ne teste pas son code
Robustesse: les jeux de données doivent contenir des incohérences
Prédiction: la sortie des tests est définie avant son lancement
Vérification : la pertinence et les résultats sont analysés
Complétude : tester ce que le programme doit et ne doir pas faire

P.18
2 - L’intégration Continue
L’intégration continue est un processus côté DEV.
Il consiste à tester et déployer sur un environnement d’intégration.
Tester aussi souvent que possible les non-rég pour détecter les bugs le plus tôt possible.
La plupart du travail est réalisé par des outils de tests automatisé.
Développement et intégration sont réalisées en parallèle pour éliminer les bugs au fur et à mesure.
La phase de test se trouve raccourcie grâce à l’intégration continue.

P.19
2 - L’intégration Continue – Focus Durée d’intégration
Avant Intégration Continue Après Intégration Continue
Durée de la phase Phase raccourcie

P.20
2 - L’intégration Continue – Focus sur les tests
La Bonne exécution des tests permet de passer aux étapes suivantes.

P.21
2 - L’intégration Continue – Focus sur les tests
L’importance des Tests et de la détection des anomalies au plus tôt.
Augmentation des
couts et des impacts
(planning, client) en cas
de détection tardive .

P.22
2 - L’intégration Continue – Focus Qualité du Code
Un code de Qualité est plus facile à maintenir.
Les bugs sont détectés et corrigés plus rapidement.
La mesure permet l’amélioration.
Identification des duplications et du code mort
Respect des règles de programmation
Détection des bugs potentiels
Evaluation de la couverture de code par les tests unitaires
Analyse de la complexité (cyclomatique)
Remontée de Métriques de qualité
Respect des règles de programmation
Nom des variables normalisées
Gestion des Exceptions
Utilisation de fonctions « deprecated »
Tailles des fonctions utilisées
Détection des bugs potentiels
Variables non initialisées
Boucles infinies
Retours de fonction non définis
Erreurs dans le transtypage
Analyse de la complexité cyclomatique
Chaque Branchement conditionnel augmente
la complexité du code.
Un code complexe est difficile à maintenir et
long à réparer.
Remontée de Métriques de qualité
Nombre de lignes de code
Nombre d’erreurs, warnings, notice.
Lignes de commentaires et couverture documentation

P.23
2 - L’intégration Continue – Focus Qualité du Code
Le gain financier sur les temps de développement
ne peut PAS toujours être compensé
par un investissement dans des serveurs plus puissants.

P.24
3 - La livraison Continue
La livraison continue est un processus d’intégration et de production.
Le but est de tester et livrer une application aux étapes suivantes du cycle de vie (recette, perfs, pré-
production).
Réalisée après validation des tests effectués en intégration.
La phase de test correspond aux tests fonctionnels , charge, sécurité…
Ces batteries de tests sont indispensables est doivent être automatisées
Le passage d’un état à l’autre est entièrement automatisé : le livrable doit être constitué de tel sorte qu’il
soit déployable en production dès la mise en recette.
Le livrable déployé est le même qu’en intégration.

P.25
3 - Livraison Continue – Focus sur les tests
Sans oublier les tests de Sécurité / Intrusion / Scalabilité / Robustesse …
SANS tests automatisés : PAS de livraison Continue !
Les TESTS sont
essentiels pour un
processus efficient !

P.26
Le déploiement continu est un processus de production.
Le but est de tester et déployer une application sur l’environnement de production.
Il est prérequis que les précédents processus aient été réalisé avec succès.
Le déploiement est automatisé et réalisé par un simple « press button »
En cas de problème un rollback est également automatisé.
4 - Le déploiement Continu

P.27
4 - Le déploiement Continu Les Risques à éviter

P.28
4 - Le déploiement Continu
Déploiement Et Rollback
Ou RollForward (si fast fix)
Application « Smiley v1.1»

Mise a disposition de fonctions au plus tôt (Time To Market)
Amélioration de la Qualité livrée
Diminution des Risques fonctionnels
Rôdage aux livraisons (Processus / Outils / Personnes)
Amélioration du Temps de Réparation
4 - Déploiement continu - Focus
Evolution du Time To Repair (TTR)
Avantages de l’Augmentation de la Fréquence de Livraison et Diminution du contenu livré :

4 - Déploiement continu - Focus

Déploiement continu : Best Practises
Environnement de Développement Intégré
Tests automatisés
Versioning , Gestion de Conf, build Tools
Bug Tracking
Outillage (déploiement, monitoring, tests)

4 – Post Mise en Production
Surveillance Continue

Monitoring des Logs
Monitoring de L’infrastructure
Monitoring du Système
Monitoring des Performances
Monitoring des Services
Monitoring de l’utilisation
Monitoring de l’application
Monitoring de l’usage des caches
Monitoring des WebServices
DashBoard de Santé
Rapport de Tendance
Analyse Prédictive
…
5 – Surveillance continue: Measure Everything !
Serveurs
(interne)
Services
(interne)
Activité
Métier
(transactionnel)
Dispo &
Perfs
(externe)
Traffic Réseau
(interne et externe)
« If it’s not Monitored, It’s
NOT in production »
« If you can NOT
measure it you can
NOT improve it »
Lord Kelvin
Embarquer les
Surveillances pour
chaque nouveau
composants livrés.

5 – Focus - Analyses Prédictives
Anticiper les problèmes et les situations anormales !
Détection des écarts basée sur des seuils configurés
Détection des anomalies basée sur des tendances et les données passées.
« Si vous rendez vos clients
mécontents dans le monde réel, ils
sont susceptibles d’en parler à 6
amis. Sur Internet, vos clients
mécontents peuvent en parler chacun
à 6000 amis » Jeff Bezos,
PDG d’Amazon

Surveillances: Best Practises
Surveillances et météo doivent être décrites dès la conception
Anticipation de l’activité Métier et des pics
Tous les éléments infra et appli doivent être monitorés
Analyse prédictive pour la détection des incidents
Reprises et Consignes d’exploitation

Schéma de principe d’Orchestration

Et du côté de L’infa ?

Industrialisation de l’Infrastructure
Provisioning d’infrastructure (Compute, Network, Storage)
Installation des images (OS) , Configuration logicielles
Déploiements infra automatisés ( code )
Mise à disposition des plateformes
Déployer, maintenir et Upgrader une infrastructure avec du code !
Elasticité (scale-in, scale-out) , robustesse, provisioning
écomissionement..Scalabilité horizontale à la demande (pic de charge, évenement métier)
Industrialisation et Automatisation des Processus (Infrastructure)
Gestion de l’infrastructure avec les paradigmes du développement
Evolution de l’infra : cycle de vie similaire au workflow applicatif
Maitrise des plateformes, Scalabilité horizontale, Versioning, APIfication des services
Les principes agiles typiques à l'application peuvent être appliqués sur l'infrastructure
Réduction des erreurs humaines / délais de mise à disposition des plateformes

Infrastructure As Code
Procédure d’installation
Provisioning
Machines

Différents Modèles de Service

Résumé des points Clés (1/2)
Tester au plus tôt et tout le long du cycle de livraison et production
Augmenter les fréquences de livraison / Diminuer le contenu livré
Disposer de processus fiables, répétables et d’outils automatisés
Industrialiser et Standardiser

1- L’infrastructure: son Provisioning, les mises à jour …
4 - Les surveillances, le monitoring et les procédures
Industrialiser et Standardiser :
2- L’usine logicielle : standardisation, framework, méthodes , outils
3- Le déploiement des applications et des configurations

Changements organisationnels
Impacts sur la Structure
Organisationnelle

Modification de la Structure Organisationnelle
Les Etudes et les Opérations se sont éloignées, leurs cultures ont divergées…
Les équipes ont été cloisonnées physiquement.
Les équipes sont placées dans des directions différentes.
Aucun plateau commun.
Les développeurs répondent à un besoin métier.
Réactivité et déploiement fréquents sont nécessaire pour les DEVs.
L’exploitation elle, doit s’assurer du maintien en condition opérationnelle du SI
Les développeurs travaillent en mode Agile.
La production travaille avec les bonnes pratiques ITIL.
Les deux méthodologies ont des objectifs partagés mais rencontrent des divergences en pratique.
Eloignement physique
Eloignement culturel
Eloignement Méthodologique

Les Etudes et les Opérations se sont éloignées, leurs cultures ont divergées…
Le problème de l’éloignement en image

A. Egels T. Chhea S. Sadirac
P. Carbasa S. Sadirac
Maintenir La disponibilité des Services en
contrôlant les évolution pour réduire les
risques et incidents
=> Minimiser les Changements
Adapter le SI aux demandes du marché en
Introduisant des évolutions applicatives,
Recherche de Flexibilité,
= > Maximiser les Changements
Couche « Hautes » :
Applications,
Composant applicatifs,
couches logicielles,
webservices,
configuration applicatives
…
Couches « Basses »
Serveurs, VMs,,
Clusters, Firewall
Réseau, Stockage,
Sauvegarde,
monitoring, patchs
sécurité…
Mise en
Production
Périmètre Application Périmètre Opération
Stabilité,
Sécurisation,
Maitrise du Risque,
ITIL
Réactivité,
Flexibilité,
Time To Market,
Agilité
Eloignement des équipes
Taylorisation des méthodes
problème: Gestion incident suite MEP !
Dev VS Ops
« Face au monde qui change il vaut mieux penser le
Changement que Changer le Pansement »

F. Sevestre
Organisation en Features Teams
Agilité et Alignement
aux Besoins
Unités
Autonome
De
Production
You Build It .. You Run It !

T. Chhea P. Carbasa S. Sadirac
F. Sevestre T. Chhea P. Carbasa S. Sadirac
La collaboration entre les Devs et les Ops représente un pilier de la transformation DevOps
La principale transformation organisationnelle consiste au décloisonnement des équipes
et au passage d’un modèle mono-disciplinaire vers des équipes pluridisciplinaires,
appelées équipes fonctionnelles ou Feature teams. Nouveau rôles : Release Manager,
Ingénieurs Devops ..
Le mécanisme de gestion des changements régule les dysfonctionnements des nouveaux
silos dans le cas d’impact d’une modification applicative sur les autres domaines
applicatifs, idem pour les changements d’infrastructures à l’initiative des exploitations.
Le support applicatif en production n’existe plus à proprement parler, il est assuré par
l’équipe applicative DevOpS. Inutile désormais d’expliquer l’impact du changement à
une équipe mutualisée de support en production.

T. Chhea P. Carbasa
F. Sevestre P. Carbasa S. Sadirac
D’autres Types d’Organisation possibles
Partage entre les équipes
des ressources spécialisées.
Polyvalence des
compétences des ressources
Equipe DEVOPS sur un
périmètre pilote
Les Dev font toutes les OPS
(cas très particulier)
Organisation traditionnelle
en silo de compétence

Transformer / Adapter l’Organisation
Changement du périmètre des activités et des rôles
Changements Techniques et Automatisation de bout en bout
You build it, you run it !

Les Axes D’améliorations et de Transformation
Où Sommes nous ?
Où va-t-on ?
Par quel Chemin ?
Que veut-on faire ?

Qu’est-ce que je
veux faire ?
Où suis-je
actuellement ?
Quelles sont mes
priorités?
Etape1Etape2Etape3
Comment
s’améliorer ?
Etape4
• Réfléchir en terme des besoins métier
• Définir des objectifs mesurables et atteignables
• Inclure des personnes clés (Dev et Ops) dans la reflexion
• Qu’est-ce qui est fait actuellement avec quelle maturité
• Ce que l’on ne fait pas mais que l’on devrait faire
• Ce qui est compliqué à faire ou source de perte d’énergie
• Définir les prochaines cibles en partant de l’état actuel
• Prévoir des changements organisationnels, technologiques, culturels
• Prioriser en fixant des objectifs ( efforts, gains, dépendances …)
• Mettre en oeuvre des Améliorations ciblées et identifies
• Roadmap et plan d’action validés par tous les acteurs
• S’appuyer sur des premiers succès mettre en oeuvre
• Envisager une extension du modèle
Le chemin Step By Step

Qu’est-ce que je
veux faire ?
Etape1
• Réfléchir en terme des besoins métier
• Définir des objectifs mesurables et atteignables
• Inclure des personnes clés (Dev et Ops) dans la réflexion
Step 1 : le besoin et les objectifs ?
Travail / Réflexion à mener (Workshop)

Define release with
business objectives
Measure to customer value
Optimize applications
Use enterprise issue
resolution procedures
Standardize and automate
cross-enterprise
Automate patterns-based
provision and deploy
Manage data and virtualize
services for test
Deliver and integrate
continuously
Link objectives to releases
Centralize Requirements
Management
Measure to project metrics
Link lifecycle information
Deliver and build with test
Centralize management and
automate test
Plan departmental releases
and automate status
Automated deployment with
standard topologies
Document objectives locally
Manage department
resources
Manage Lifecycle artifacts
Schedule SCM integrations
and automated builds
Test following construction
Plan and manage releases
Standardize deployments
Monitor resources
consistently
Collaborate Dev/Ops
informally
Plan and source
strategically
Dashboard portfolio
measures
Monitor using business and
end user context
Centralize event notification
and incident resolution
Automate problem isolation
and issue resolution
Optimize to customer KPIs
continuously
Improve continuously with
development intelligence
Test Continuously
Manage environments
through automation
Provide self-service build,
provision and deploy
P
r
o
g
r
è
s
Step 2 : l’état des lieux actuel ?

Step 2 : l’état des lieux actuel ? (autre exemple)
P R O G R E S

Step 3 - Les Priorités

Layer Rubriques Axes d’optimisations
Amélioration
&
Collaboration
Culture, Processus
& Outillage
Amélioration des processus dev/prod, alignement et partage des outils, collaboration
des équipes tout le long du cycle de MEP, standardisation et automatisation de la
chaine de déploiement. Adoption des processus et des outils par les équipes.
Rédaction d’un kit et manuel d’utilisation (processus, outils, méthodes). Amélioration
des catalogues. Standardisation & Industrialisation .
Monitoring & KPI
Indicateurs techniques et métiers de bonne santé des applis partagés (choix des
outils, health checks, .), suivi de l’efficience des transformations techniques et orga.
Appli
Infra
Fiabilisation des
MEP
Mise en place de Quality Gates, conception de l’application pour supporter le ZDD et
l’ouverture progressive (feature flags), scalabilité horizontale , HA applicative.
Gestion des logs et
des erreurs
Amélioration des messages, outils de concentration et d’analyse de logs, surveillances
spécifiques de patterns d’erreurs des logs. Procédures de rattrapage en cas d’erreur.
Sécurité
Processus clairement établi, liste des patchs à appliquer, règles de sécurité à
appliquer. Ensemble des tests nécessaire pour un Go Live ou Release formalisés.
Maintien en
condition Op
Gestion des montées de version des middlewares, migrations techniques, fenêtre
spécifiques pour ces opérations. Mise en place du Mécanisme de dette technique.
Zero Downtime
Deploiement
Déploiement progressif (feature flags) ou partielle (canary testing) de fonctionnalités.
pattern green / blue … Gestion de l’AB Testing …
Robustesse, tenue
à la charge
Suppression des SPOF , mise en place de modes dégradés et de mécanismes de
protection contre les saturations , plans d’action de test en charge, plan d’ajout de
capacité.
Evolutions de
l’infrastructure
Adaptation de l’infrastucture aux patterns de ZDD, (duplication des chaines
applicatives…), Infrastructure as a code , amélioration du provisioning, catalogue de
service Infrastructure, optimisation des performances, focus sur la scalabilité. Mise en

Processus Etape 1 – Lean & Optimisation

Définir plusieurs type de « Quality Gates » pour la gestion du cycle de vie d’une application.
Les Quality Gates représentent toutes les étapes de validation d’une application avant sa mise en
production.
Le passage par tel ou tel Quality Gate est déterminé en fonction de la nature de la release (mineur,
majeur, nouvelles fonctionnalités) ou en fonction d’évènements (correction anomalie …)
Les règles seront établies dans un comité regroupant les études et l’exploitation.
Chaque Quality Gates contient des contrôles spécifiques (livrables, PV , prérequis, ensemble de tests …)
Le contenu des Quality Gates est défini en amont du cycle et avant le déploiement d’une release et
intégré dans un outillage opérationnel.
Les Quality Gates ou Cycle de vie d’une application

Les Quality Gates ou Cycle de vie d’une application

Objectif : garantir que les déploiements peuvent se faire sans impact sur le service et sa
disponibilité.
C’est là qu’intervient le Zero Downtime Deployment (ZDD), qui permet de déployer une
nouvelle version d’un système sans interrompre le bon fonctionnement du service.
Comment s’assurer d’un déploiement « sans accroc » ?
La mise en oeuvre du Zero Downtime Deployment se base sur un certain nombre de patterns et
de bonnes pratiques (devant être prises en compte dès la conception logicielle)
Zero Downtime Deployment

Blue / Green Deployment
C’est le pattern classique de ZDD.
Il suppose que l’application soit hébergé sur au moins deux chaînes applicatives, puisque
l’objectif est de déployer la version N+1 d’une application sur une des chaînes, tandis que le
service est maintenu sur les chaînes encore en version N.
Zero Downtime Deployment
Difficultés : lors de modification de structure des données (opérations BDD complexes)
L’application doit pouvoir gérer la bascule et la réplication des données.

Pattern Blue Green

Canary Release
Les mécanismes sont identiques au Blue/Green Deployment.
Permet de confronter la version N+1 à une population restreinte d’utilisateurs.
La majorité des utilisateurs ont accès à la version N.
Zero Downtime Deployment & AB Testing
Utilisé par Facebook pour déployer en 1er aux collaborateurs puis à tous les utilisateurs si ok

Canary Release
Le « testing en production » est probablement l’une des approches les plus novatrices : déployer une
nouvelle fonctionnalité dans l’application en production tout en maitrisant l’impact. Cette maitrise peut
correspondre par exemple à un déploiement sur un pourcentage d’utilisateur ayant un profil identifié ou
une localisation géographique donnée par exemple.
A/B Testing : Tester les nouvelles fonctionnalités sur le site de production

Features Flags
Le code Applicatif embarque des modifications permettant de tagger les fonctionnalités
L’execution du même code détermine si la fonctionnalité doit être activée ou non.
Permet d’activer des fonctionnalités selon des critères spécifiques (IP, utilisateurs, events…)
La fonctionnalité peut être activée / désactivée sans redéployer
Zero Downtime Deployment & AB Testing
Difficultés: Maintenance du code, gestion des tests, Activation et support des fonctionnalités.
Nécessite beaucoup de rigueur et un pilotage fin de l’activité.

Features Flags (Modification du code applicatif)
Présentation d’un cas d’usage simple
Des use Cases plus complexes peuvent être mis en œuvre (cibler des utilisateurs selon une
multitude de critères …)

Etudes – Amélioration des Logs
Des logs explicites pour permettre une
exploitation efficace et la détection des
évènements importants.

Le partage d’informations et de procédures permettant aux DEVs de s’impliquer dans la « stabilité de la
production » et d’améliorer, en relation avec le département d’Exploitation, la sûreté de
fonctionnement des services IT :
• Automatisation des procédures d’installation des correctifs.
• Automatisation des remontées de compte rendu d’exécution pour les programmes en erreur
• Automatisation des consignes de reprise en cas d’incident
• Identification des Applicatives vs alertes d’Infrastructure
• Collaboration et Partage des informations de Tenue à la charge, Performance et Capacité
• Amélioration du Monitoring existants
• Analyses Prédictives
Opérations
automatisationMonitoring

• Amélioration des tests (fonctionnels, logiciels, …) et automatisation end to end (scénarii ,
gestion des jeux de données)
• Prise en compte des aspects de déploiements progressif dans le développement (ex Features
Flags )
• Gestion de version des logiciels et d’intégration qui alimentent l’outil d’installation et de
déploiement en production
• Augmentation de la robustesse des logiciels qui ne doivent pas défaillir lors de la réception
de flux de données incorrects (foolproof)
• Messages d’alertes pertinents (logs, monitoring, …) et suppression des bruits (alertes
inutiles)
• Fourniture d’éléments (techniques et métier) permettant de prévoir les besoins capacitaires
• Conception et mise en place de messages alimentant des tableaux de bord temps réel de
suivi du bon fonctionnement et du volume d’activité métier.
• Prendre en compte des aspects de monitoring des fonctions dans le développement
Etudes
Reportinget
Capacité
Déploiement,testset
automatisation

P
r
o
g
r
è
s
Step 4 : Comment s’améliorer ?

Fixer un planning ambitieux mais
réaliste et adapté au contexte
Step 4 : Comment s’améliorer ?

Bénéfices / Risques de la Démarche
Approche innovante, démarche appliquée dans le Cloud
Alignement de la stratégie Digital avec les besoins Métier
Accélération des temps, maitrise, Répétabilité des déploiements
Diminution drastique des Erreurs Humaines
Expertise internalisée (Equipe Produit DEVOPS)
Périmètre de responsabilité éclairci
Optimisation de l'utilisation des compétences et polyvalence
Plus de Focus sur les besoins métier
Bénéfices
Coût de transformation / Accompagnement
Objectifs Métier non suffisamment définis
Partage du Risque opérationnel (limitée)
Modification du périmètre de responsabilité existant
Maintien d’une Standardisation Transverse (Normes, Protocoles, …)
Manque d’automatisation des tests (unitaires, fonctionnels, …)
Réticence au Changement / Manque de Sponsoring
Risques

REFERENCES
http://www.it-expertise.com/devops-le-changement-necessaire-pour-les-applications-dentreprise/
http://poesi.fr/wp-content/uploads/2013/09/Les-10-pratiques-pour-une-d%C3%A9marche-DevOps-efficace.pdf
http://niek.bartholomeus.be/2013/01/28/introducing-a-devops-culture-in-a-traditional-enterprise/
http://www.marte.fr/livres-blancs/la-revolution-devops/
http://culturedevops.com/
http://www.arrkgroup.com/thought-leadership/what-is-devops/
http://107.23.68.153/2013/09/12/survey-devops-an-overnight-success-because-it-works/
http://fr.slideshare.net/mostefaiamine/gnie-logiciel-les-tests?next_slideshow=2
http://blog.xebia.fr/wp-content/uploads/2010/12/Livre-blanc-qualit%C3%A9-logicielle.pdf
http://fr.slideshare.net/SonatypeCorp/devops-and-continuous-delivery-reference-architectures?qid=ec0f170d-
e982-433c-b40d-5e94343db650&v=default&b=&from_search=2
http://fr.slideshare.net/mostefaiamine/cours-gnie-logiciel-cours-2-cycles-de-vie?next_slideshow=3
http://blog.octo.com/devops/
http://fr.slideshare.net/CdrickLunven/introduction-to-feature-toggle-and-ff4?qid=69e7b650-9406-4687-872d-
d2782acd2d79&v=default&b=&from_search=1
https://www.ssw.com.au/ssw/Consulting/DevOps.aspx
http://www.lukew.com/ff/entry.asp?1460
http://product.hubspot.com/blog/how-we-deploy-300-times-a-day
http://fr.slideshare.net/ufried/devops-for-developers-28043923?related=1
http://fr.slideshare.net/ufried/patterns-of-resilience
http://fr.slideshare.net/rfelden/devops-mission-impossible?qid=31fb86ab-662b-4ffc-a90b-
5b52c494645a&v=&b=&from_search=3

Presentation DevOps : enjeux , objectifs, consequences

Contenu connexe

Tendances (20)

Similaire à Presentation DevOps : enjeux , objectifs, consequences (20)

Presentation DevOps : enjeux , objectifs, consequences

Notes de l'éditeur