Introduction

Philosophie et Culture de la démarche

DEVOPS
NAJAH IDRISSI MOULAY RACHID

Expert IT Reconnu Auprès de la Banque MondialeExpert en transorfmation

SI et Digitale
Consultant séminariste et Formateur depuis 2004
Instructeur MCT Microsoft Cerfied Trainer
Detenant plus de 34 Certifications éditeurs et organisationnelles

Email : moulayrachid@[Link] / GSM : 00 212 6 68 97 65 62

 DEVOPS … par où commencer … ?

DevOOOpS C'est Quoi ?

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.

 La Philosophie « DEVOPS »

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.

 La Philosophie « DEVOPS »

Les Axes essentiels pour la mise en Place du DEVOPS

Un Revirement culturel ET une Collaboration des équipes

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.

Un Outillage Automatisé (intégration, livraisons, déploiements, tests…)

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.

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 !
 La Philosophie « DEVOPS »

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.
 La Philosophie « DEVOPS »
Culture de Collaboration Infrastructure As Code
Objectifs communs entre les équipes Gestion de l’infrastructure par du Code
Des Processus partagés et adoptés Même Cycle de livraison que l’applicatif
Des équipes fonctionnelles décloisonnées. 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
 La Philosophie « DEVOPS »

Résumé des points Clés

La satisfaction client avant tout !

Une nouvelle Culture et une Collaboration des équipes

Une Agilité sur l’ensemble de la chaine (infrastructure, développement, déploiement )

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 (2016!)

[Link] 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 !

Le nombre de
déploiement par jour
n’est pas une fin en
soi, l’objectif est de
.. Et vous .. ? pouvoir livrer quand
on veut livrer !
 Les Processus du DEVOPS
Vision Synthétique

DEV OPS
 Les Processus du DEVOPS
Vision intégrée
Accélérer le Time To Market 6
Feedback Continu
Equilibrer vitesse, coût, qualité Update du statut / préconisations
Amélioration Continue
et risque. Retour à chaque étape
Etablir une cible à atteindre
Réduire le temps de retour Client Mise en œuvre de Plan d’amélioration
Post implémentation review …

Développements Agile 5
1 Cycles itératifs (Sprint)
Surveillance continue
Backlog produit
Monitoring & Supervisions
Détection des anomalies

Intégration Continue
2 Construction package
Tests (unitaires, code…)

Déploiement en UAT/PPD Déploiement en Production

3 Même livrable Push button 4
Tests (charge, perfs, intrusion..) Installation & Rollback automatisé
 Les Processus du DEVOPS
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.

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

Quelques Méthodologies Agiles :

Scrum, Extreme Programing, Feature Driven Developpement, Kanban …
 Les Processus du DEVOPS

Développement: Best Practises

Fonctionnalités conçues pour être indépendantes

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

Environnement iso Production (ou quasi)

Complétude : tester ce que le programme doit et ne doir pas faire

 Les Processus du DEVOPS
1 – Développement : Les Méthodologies Agiles : Focus SCRUM

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

Les Tests : Best Practises

Indépendance : le développeur ne teste pas son code

Prédiction: la sortie des tests est définie avant son lancement

Vérification : la pertinence et les résultats sont analysés

Robustesse: les jeux de données doivent contenir des incohérences

Complétude : tester ce que le programme doit et ne doir pas faire

 Les Processus du DEVOPS

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.18
 Les Processus du DEVOPS

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.19
 Les Processus du DEVOPS

2 - L’intégration Continue – Focus sur les tests

La Bonne exécution des tests permet de passer aux étapes suivantes.

P.20
 Les Processus du DEVOPS

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.21
 Les Processus du DEVOPS

Respect des règles de programmation

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

P.22
 Les Processus du DEVOPS

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.23
 Les Processus du DEVOPS

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.24
 Les Processus du DEVOPS

Les TESTS sont

3 - Livraison Continue – Focus sur les tests
essentiels pour un
processus efficient !

Sans oublier les tests de Sécurité / Intrusion / Scalabilité / Robustesse …

SANS tests automatisés : PAS de livraison Continue !

P.25
 Les Processus du DEVOPS

4 - Le déploiement Continu

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é.

P.26
 Les Processus du DEVOPS

4 - Le déploiement Continu Les Risques à éviter

P.27
 Les Processus du DEVOPS

4 - Le déploiement Continu
Application « Smiley v1.1»

Déploiement Et Rollback
Ou RollForward (si fast fix)

P.28
 Les Processus du DEVOPS

4 - Déploiement continu - Focus

Avantages de l’Augmentation de la Fréquence de Livraison et Diminution du contenu livré :

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

Evolution du Time To Repair (TTR)

 Les Processus du DEVOPS

4 - Déploiement continu - Focus

 Les Processus du DEVOPS

Déploiement continu : Best Practises

Environnement de Développement Intégré

Versioning , Gestion de Conf, build Tools

Bug Tracking

Tests automatisés

Outillage (déploiement, monitoring, tests)

 Les Processus du DEVOPS

4 – Post Mise en Production

Surveillance Continue
 Les Processus du DEVOPS

Serveurs
5 – Surveillance continue: Measure Everything ! (interne)

Monitoring des Logs

Monitoring de L’infrastructure « If you can NOT
Services
Monitoring du Système measure it you can (interne)
Monitoring des Performances NOT improve it »
Lord Kelvin
Monitoring des Services
Monitoring de l’utilisation Activité
Monitoring de l’application Métier
Embarquer les
Monitoring de l’usage des caches (transactionnel)
Surveillances pour
Monitoring des WebServices
chaque nouveau
DashBoard de Santé Dispo &
composants livrés.
Rapport de Tendance Perfs
Analyse Prédictive (externe)

…
« If it’s not Monitored, It’s
NOT in production »
Traffic Réseau
(interne et externe)
 Les Processus du DEVOPS
« Si vous rendez vos clients
5 – Focus - Analyses Prédictives mécontents dans le monde réel, ils
sont susceptibles d’en parler à 6
Anticiper les problèmes et les situations anormales ! amis. Sur Internet, vos clients
mécontents peuvent en parler chacun
à 6000 amis » Jeff Bezos,
Détection des écarts basée sur des seuils configurés
PDG d’Amazon

Détection des anomalies basée sur des tendances et les données passées.
 Les Processus du DEVOPS

Surveillances: Best Practises

Surveillances et météo doivent être décrites dès la conception

Tous les éléments infra et appli doivent être monitorés

Analyse prédictive pour la détection des incidents

Anticipation de l’activité Métier et des pics

Reprises et Consignes d’exploitation

 Les Processus du DEVOPS

Schéma de principe d’Orchestration

Les Processus du DEVOPS

Et du côté de L’infa ?
 Les Processus du DEVOPS

Industrialisation de l’Infrastructure

Industrialisation et Automatisation des Processus (Infrastructure)

Provisioning d’infrastructure (Compute, Network, Storage)
Installation des images (OS) , Configuration logicielles
Déploiements infra automatisés ( code )
Mise à disposition des plateformes

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

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)
 Les Processus du DEVOPS

Infrastructure As Code
Procédure d’installation

Machines

Provisioning
 Les Processus du DEVOPS

Différents Modèles de Service

 Les Processus du DEVOPS

Différents Modèles de Service

Les Processus du DEVOPS
 Les Processus du DEVOPS

Résumé des points Clés (1/2)

Industrialiser et Standardiser

Augmenter les fréquences de livraison / Diminuer le contenu livré

Disposer de processus fiables, répétables et d’outils automatisés

Tester au plus tôt et tout le long du cycle de livraison et production

 Les Processus du DEVOPS

Résumé des points Clés (2/2)

Industrialiser et Standardiser :

1- L’infrastructure: son Provisioning, les mises à jour …

2- L’usine logicielle : standardisation, framework, méthodes , outils

3- Le déploiement des applications et des configurations

4 - Les surveillances, le monitoring et les procédures

 Impacts sur la Structure
Organisationnelle

Changements organisationnels
 Modification de la Structure Organisationnelle

Les Etudes et les Opérations se sont éloignées, leurs cultures ont divergées…

Eloignement physique
Les équipes ont été cloisonnées physiquement.
Les équipes sont placées dans des directions différentes.
Aucun plateau commun.

Eloignement culturel
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

Eloignement Méthodologique
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.
 Modification de la Structure Organisationnelle

Les Etudes et les Opérations se sont éloignées, leurs cultures ont divergées…

Le problème de l’éloignement en image

 Modification de la Structure Organisationnelle
Dev VS Ops

Périmètre Application Périmètre Opération

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

You Build It .. You Run It !

Unités
Autonome
De
Production
F. Sevestre

Organisation en Features Teams

Agilité et Alignement
aux Besoins
 Modification de la Structure Organisationnelle

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 changementsT.d’infrastructures
F. Sevestre Chhea à l’initiative des
P. Carbasa exploitations.
S. Sadirac

T. Chhea P. Carbasa S. Sadirac

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.

You Build It .. You Run It !

 Modification de la Structure Organisationnelle

D’autres Types d’Organisation possibles

Organisation traditionnelle
en silo de compétence

Les Dev font toutes les OPS

(cas très particulier)

Partage entre les équipes

des ressources spécialisées.
F. Sevestre P. Carbasa S. Sadirac

T. Chhea P. Carbasa Polyvalence des

compétences des ressources

Equipe DEVOPS sur un

périmètre pilote

You Build It .. You Run It !

 Modification de la Structure Organisationnelle

Résumé des points Clés (1/2)

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 !

 Modification de la Structure Organisationnelle

Résumé des points Clés (2/2)

Les Axes D’améliorations et de Transformation

Que veut-on faire ? Où Sommes nous ?

Par quel Chemin ?

Où va-t-on ?
 Les Axes D’améliorations et de Transformation

Le chemin Step By Step

• Réfléchir en terme des besoins métier

Etape 1

Qu’est-ce que je
veux faire ? • 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é

Etape 2

Où suis-je
• Ce que l’on ne fait pas mais que l’on devrait faire
actuellement ? • Ce qui est compliqué à faire ou source de perte d’énergie

• Définir les prochaines cibles en partant de l’état actuel

Etape 3

Quelles sont mes

• Prévoir des changements organisationnels, technologiques, culturels
priorités?
• Prioriser en fixant des objectifs ( efforts, gains, dépendances …)

• Mettre en oeuvre des Améliorations ciblées et identifies

Etape 4

Comment • Roadmap et plan d’action validés par tous les acteurs

s’améliorer ? • S’appuyer sur des premiers succès mettre en oeuvre
• Envisager une extension du modèle
 Les Axes D’améliorations et de Transformation

Step 1 : le besoin et les objectifs ?

• Réfléchir en terme des besoins métier

Etape 1

Qu’est-ce que je
veux faire ? • Définir des objectifs mesurables et atteignables
• Inclure des personnes clés (Dev et Ops) dans la réflexion

Travail / Réflexion à mener (Workshop)

 Les Axes D’améliorations et de Transformation

Step 2 : l’état des lieux actuel ?

Define release with Improve continuously with Manage environments Automate problem isolation
business objectives development intelligence through automation and issue resolution
Measure to customer value Test Continuously Provide self-service build, Optimize to customer KPIs
provision and deploy continuously

P Plan and source Manage data and virtualize Standardize and automate Optimize applications
strategically services for test cross-enterprise
r Dashboard portfolio Deliver and integrate Automate patterns-based Use enterprise issue
resolution procedures
o measures continuously provision and deploy

g
r Link objectives to releases Link lifecycle information Plan departmental releases Monitor using business and
Centralize Requirements Deliver and build with test and automate status end user context
è Management Centralize management and Automated deployment with Centralize event notification
standard topologies and incident resolution
s Measure to project metrics automate test

Manage Lifecycle artifacts Monitor resources

Document objectives locally Plan and manage releases consistently
Schedule SCM integrations
Manage department and automated builds Standardize deployments Collaborate Dev/Ops
resources informally
Test following construction
 Les Axes D’améliorations et de Transformation

Step 2 : l’état des lieux actuel ? (autre exemple)

PROGRES
Les Axes D’améliorations et de Transformation

Step 3 - Les Priorités

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

Processus Etape 1 – Lean & Optimisation

 Les Axes D’améliorations et de Transformation

Les Quality Gates ou Cycle de vie d’une application

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 Axes D’améliorations et de Transformation

Les Quality Gates ou Cycle de vie d’une application

 Les Axes D’améliorations et de Transformation

Zero Downtime Deployment

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)
 Les Axes D’améliorations et de Transformation

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.

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.
 Les Axes D’améliorations et de Transformation
Pattern Blue Green
 Les Axes D’améliorations et de Transformation

Zero Downtime Deployment & AB Testing

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.

Utilisé par Facebook pour déployer en 1er aux collaborateurs puis à tous les utilisateurs si ok
 Les Axes D’améliorations et de Transformation
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

 Les Axes D’améliorations et de Transformation

Zero Downtime Deployment & AB Testing

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

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é.
 Les Axes D’améliorations et de Transformation
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 …)
 Les Axes D’améliorations et de Transformation

Etudes – Amélioration des Logs

Des logs explicites pour permettre une

exploitation efficace et la détection des

évènements importants.
 Les Axes D’améliorations et de Transformation

Opérations

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

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

Monitoring

• Collaboration et Partage des informations de Tenue à la charge, Performance et Capacité

• Amélioration du Monitoring existants

• Analyses Prédictives
 Les Axes D’améliorations et de Transformation

Etudes

• Amélioration des tests (fonctionnels, logiciels, …) et automatisation end to end (scénarii ,

gestion des jeux de données)
Déploiement , tests et

• Prise en compte des aspects de déploiements progressif dans le développement (ex Features
automatisation

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)
Reporting et

•
Capacité

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
 Les Axes D’améliorations et de Transformation

Step 4 : Comment s’améliorer ?

P
r
o
g
r
è
s
 Les Axes D’améliorations et de Transformation

Step 4 : Comment s’améliorer ?

Fixer un planning ambitieux mais

réaliste et adapté au contexte
 Bénéfices / Risques de la Démarche

Bénéfices

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

Risques

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
On Continue ?