​COMPRENDRE

LE DEVOPS POUR
LE METTRE EN
ŒUVRE
MEHDI EL KOUHEN

LIVRE BLANC - JUILLET 2022

 PRÉAMBULE 05

INTRODUCTION 06

PARTIE 1 08
SOMMAIRE
PARTIE 2 16

PARTIE 3 23

PARTIE 4 36
 PARTIE 5 51

PARTIE 6 57

PARTIE 7 64

CONCLUSION 82

BIBLIOGRAPHIE 84
 MEHDI EL KOUHEN
J’occupe depuis trois ans le poste d’architecte DevOps
& Cloud chez Ippon Technologies à Nantes.
Mon rôle consiste à intervenir sur la mise en œuvre
d’architectures microservices, en m’intéressant tout
particulièrement aux aspects DevOps et Cloud.

Je suis également Senseï du programme BlackBelt, qui

permet le développement de compétences en interne.
Je mentore celles et ceux qui souhaitent améliorer leur
expertise Cloud & DevOps.

N’hésitez pas à me contacter sur LinkedIn pour

échanger, et à visiter le blog Ippon pour y retrouver
quelques-uns de mes articles !
 PRÉAMBUL
Le DevOps est un mouvement très en
vogue; les attentes des entreprises sont
très variées : de l’automatisation des
déploiements jusqu’au déploiement
continu en s’appuyant sur une
collaboration accrue entre les équipes
produit et les exploitants.

J’ai souhaité faire un tour d’horizon

des impacts de cette démarche sur les
processus (déploiement, supervision…) et
outillages associés.

Ensuite, j’ai souhaité montrer que le

DevOps apporte des changements
organisationnels importants, comme la
suppression des silos entre équipes pour
aligner les équipes sur l’apport de valeur
aux clients.

Pour terminer, j’ai souhaité apporter

quelques clés sur la mise en place d’une
démarche DevOps : je vous partage des
bonnes pratiques à suivre ainsi que des
points de vigilance.
 Le DevOps est une évolution du
NTRODUCTION mouvement agile qui intègre
les exploitants dans le cycle de
développement des applications afin
d’aligner toutes les équipes sur l’apport
de valeur aux clients et donc d’améliorer
la satisfaction client.

Ce mouvement repose sur les mêmes

principes que l’agilité : prioriser la
satisfaction du client, collaborer et
partager les responsabilités, accepter
le changement, favoriser l’excellence
technique…

Voici quelques déclinaisons de ces

principes d’un point de vue DevOps.

Concernant la priorisation de la
satisfaction du client, l’automatisation des
tâches permet de livrer fréquemment de
la valeur aux clients. La CICD, qui est le
point central de l’automatisation, fluidifie
toutes les étapes du développement
jusqu’au déploiement des applications et
de l’infrastructure.
La collaboration entre équipe produit et Dans la partie Contexte historique, nous
exploitants permet une compréhension décrirons l’émergence du mouvement
des enjeux de chacun. Elle donne aussi DevOps, puis nous en présenterons
l’opportunité de traiter collectivement successivement ses Valeurs, ses
des points connexes à ces métiers, Processus et ses Outils.
comme la mise en place d’une plateforme
d’observabilité, le contrôle des coûts... Dans la partie Organisation des
L’automatisation est un élément équipes, nous présenterons différentes
fondamental pour accepter le organisations qui encouragent une
changement. Les différents types de collaboration entre les équipes de
tests automatisés (E2E, performance, développement et les exploitants.
chaos…) permettent de s’assurer du bon
fonctionnement des applications. La mise Dans la partie Trois voies, nous
en place d’une plateforme d’observabilité aborderons ensuite la métaphore des
simplifie le diagnostic en cas d’anomalie trois voies qui raconte sous forme
et accélère ainsi leur correction. d’histoires des stratégies de mise en place
du DevOps.
Favoriser l’excellence technologique
permet de réduire la dette technique, Dans la partie Mettre en place une
de remettre en question d’anciens choix démarche DevOps, nous évoquerons des
et de les corriger suite à une meilleure points importants d’une transformation
compréhension des besoins et des DevOps.
aspects techniques (services utilisés,
modèles d’architecture…). Puis dans la conclusion, nous
récapitulerons les bénéfices apportés par
La mise en œuvre de ces principes crée la mise en place d’une démarche DevOps.
un cercle vertueux. La collaboration entre
les équipes produits et exploitants génère
de nouveaux domaines d’expertise (à
cheval entre ces deux domaines) qui sont
essentiels pour l’amélioration continue.
CONTEXTE
HISTORIQUE

01
8 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE
POUR COMPRENDRE Les méthodologies projet ont évolué,
depuis, pour apporter plus de flexibilité
L’ÉMERGENCE DU dans la planification et aboutir aux

MOUVEMENT DEVOPS, méthodes agiles qui sont orientées

satisfaction du client plutôt que suivi d’un
NOUS LE RESTITUONS DANS plan défini. Cette méthodologie a évolué

SON CONTEXTE HISTORIQUE. pour faire naître le mouvement DevOps

qui prône une forte collaboration entre
les équipes produit et les exploitants. Ceci
La méthodologie projet dite “en cascade” représente la suppression d’une première
(waterfall) apparaît dans les années frontière entre les développeurs et les
1970 (cf. article Royce, 1970). L’idée est exploitants.
qu’un projet est une succession linéaire
d’étapes : de la spécification des besoins à En parallèle de ces évolutions sur les
l’exploitation des applications en passant méthodologies de projet, de nouveaux
par le développement. fournisseurs de services, de plateformes
et d’infrastructures arrivent sur le
Dans les projets en cascade, les différentes marché : c’est le début du Cloud.
équipes ont une relation contractuelle :
chaque équipe livre un contrat à l’équipe
en aval qui doit le respecter. En effet,
l’équipe métier livre un document de
spécifications fonctionnelles à l’équipe de
développement qui code l’application puis
rédige et fournit un dossier d’exploitation
aux exploitants.

Mais, pour de nombreuses raisons, cette

méthodologie ne fonctionne pas :
— Les relations contractuelles entre
les équipes sont conflictuelles : les
exigences définies par une équipe
en amont ne sont pas tenables par
l’équipe en aval.
— Les applications construites ne
répondent pas bien aux besoins
des utilisateurs (pas de prise
en compte du feedback des
utilisateurs).

9
Le succès du Cloud repose en partie
sur la mise à disposition de services
d’Infrastructure (VMs, bus de messages...)
par l’intermédiaire d’applications et
d’APIs Web. Les développeurs utilisent
rapidement ces APIs pour automatiser
le déploiement des ressources
d’Infrastructure.

Avant l’arrivée des services Cloud, la

gestion des ressources était statique.
En début de projet, les projets devaient
évaluer leurs besoins en ressources (VM,
disque…), les acheter et les installer. La
durée entre l’évaluation des besoins et la
mise à disposition des ressources pouvait
être de l’ordre de plusieurs mois.

Avec l’arrivée des services Cloud, les projets

gèrent les ressources dynamiquement.
Ainsi, les utilisateurs des services Cloud
peuvent déployer des ressources à la
demande (en quelques minutes) et les
restituer aussi vite en n’étant facturé
que sur le temps d’utilisation. Cette
gestion dynamique permet de créer
des environnements pour des besoins
particuliers (démo, test…) ou encore de
redimensionner l’infrastructure (scaling
horizontal) en fonction de la charge.

C’est ainsi que l’arrivée du Cloud participe

à son tour à la suppression d’une autre
frontière entre les développeurs et les
exploitants.

10
01 ORIGINES DU DEVOPS

L’ORIGINE DU MOUVEMENT Dans le cadre de ce projet, il collabore avec

des développeurs (organisés en agile) et
DEVOPS EST ATTRIBUÉE des exploitants. Frustré de la différence

À PATRICK DEBOIS QUI d’organisation entre ces deux équipes, il

a l’intuition de généraliser les pratiques
PARTICIPE EN 2007 À UN agiles aux métiers d’exploitation.

PROJET DE MIGRATION D’UN Patrick Debois crée, par ailleurs, en 2009,

DATA CENTER EN BELGIQUE. un groupe de discussion sur la pratique
de l’agilité pour l’administration système.
Certaines discussions abordent des sujets
très actuels comme les stratégies de test
d’infrastructure. En 2009, les solutions de
virtualisation de PC x86 existent depuis
une dizaine d’années et commencent à
permettre ce genre d’usage.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 11

02 ÉVOLUTIONS DU DEVOPS

Depuis son émergence, le mouvement 1. SRE

DevOps a inspiré d’autres mouvements
similaires : « It’s what happens when you ask a software
— Le Site Reliability Engineer (SRE), engineer to design an operations function »
pour améliorer la fiabilité des sites,
Ben Treynor, Google
— Le DevSecOps, pour les aspects de
sécurité,
Comme nous l’avons vu précédemment,
— Le FinOps, pour les aspects
le DevOps est un ensemble de principes
financiers,
qui encouragent la collaboration entre
— Le AIops, pour l’Intelligence
les équipes produit et les exploitants.
Artificielle,
Le SRE (Site Reliability Engineer) est une
— Le DataOps, pour la gestion des
réponse concrète à la philosophie DevOps :
données,
c’est un ensemble de bonnes pratiques et
— ....
de convictions.

Nous présentons succinctement ci-

Ce mouvement est d’abord apparu
dessous les mouvements SRE, DevSecOps
en interne chez Google. Mais comme
et FinOps.
les équipes Google ont compris que
les concepts portés (disponibilité,
supervision...) étaient nécessaires
pour communiquer avec leurs clients,
ils ont rendu leur démarche publique
notamment sur le site web Site Reliability
Engineering.

12
Une des convictions fondamentales Tandis que le mouvement DevOps
du SRE est que les sujets d’exploitation rappelle que pour instaurer un climat de
peuvent se résoudre par du logiciel. confiance, l’entreprise doit accepter les
En utilisant les bons outils, ou en erreurs, le SRE détermine le SLO (Service
développant de nouveaux outils si Level Objective) des services et automatise
nécessaire, il est possible par exemple de le processus de reprise des pannes pour
détecter des anomalies sur les services respecter le SLO. Cette garantie de SLO
et de les corriger automatiquement réduit le stress engendré par les pannes
(détection par exemple d’un disque plein ainsi que leurs impacts.
qui déclenche son redimensionnement).
Pour qu’un SRE puisse mener à bien ses
En plus de ces convictions, le SRE apporte deux missions (exploiter la plateforme et
des réponses précises aux principes automatiser les tâches), son planning doit
DevOps. Voici deux exemples : être adapté. Les SRE Google consacrent 50 %
de leur temps à la gestion des systèmes
Là où le mouvement DevOps propose de (analyse - résolution des pannes...) et
supprimer les silos entre développeurs et 50 % à développer la plateforme.
exploitants, le mouvement SRE propose
d’atteindre cet objectif en co-développant
avec les développeurs des outils pour
simplifier les tâches quotidiennes
(versioning des artefacts, déploiement des
applications...).

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 13

2. DEVSECOPS
Le DevSecOps (Development - Security - Le DevSecOps encourage la mise en place
Operations) est une évolution du DevOps de bonnes pratiques. En voici trois.
qui intègre les aspects sécurité dans le
cycle de vie du développement logiciel. Une première bonne pratique est
L’invention du terme DevSecOps est évidemment la formation des équipes aux
généralement attribuée à Shannon Lietz vulnérabilités des logiciels (cf. site OWASP
qui a aussi participé à la rédaction du qui liste les vulnérabilités principales ainsi
manifeste DevSecOps. que les techniques de défense) ainsi que
la mise en place d’un processus de veille
L’apparition du mouvement DevSecOps (cf. site de l’ANSSI qui permet de suivre les
s’explique par différentes raisons. alertes et de déclarer les incidents).

Pour commencer, le DevSecOps est Une deuxième est l’intégration des

une suite logique de l’émergence des outils de sécurité dans les processus
méthodes agiles et du mouvement d’automatisation (analyse statique du code
DevOps qui encourage la collaboration et analyse dynamique des applications) et
entre toutes les équipes : les équipes de supervision des environnements.
produit, les exploitants, la sécurité...
Une troisième est la recherche proactive
Ensuite, l’émergence des architectures des failles de sécurité. Ceci peut être
microservices, pour remplacer les obtenu par exemple en mettant en
architectures monolithiques, nécessite de place d’un côté des équipes “Rouges”
déterminer et implémenter les exigences qui cherchent des failles de sécurité et
de sécurité service par service. cherchent à les exploiter et de l’autre
côté des équipes “Bleues” qui gèrent les
Pour terminer, le nombre d’attaques incidents de sécurité.
(phishing, DDOS, ransomware) n’a jamais
été aussi important et est en toujours en
augmentation.

14
3. FINOPS
Le FinOps (Finance - Operations) est une Un autre site intéressant est le site finops.
autre évolution de la démarche DevOps world, qui publie des bonnes pratiques
qui incite à maximiser l’apport de valeurs FinOps en les organisant par niveau
aux clients en guidant les choix techniques de maturité de l’entreprise sur le sujet
par des informations de coûts. (démarrage, pérennité et généralisation)
et par processus (stratégie, gouvernance,
Pour mettre en place une démarche build…).
FinOps, il existe aujourd’hui de nombreuses
sources d’informations. Un premier exemple de mise en place
du FinOps est l’analyse régulière par les
Le site finops.org énumère notamment équipes des rapports de facturation : si
les principes du mouvement FinOps : un service coûte cher, l’équipe modifie
— Les équipes doivent être son utilisation pour réduire les coûts ou
responsables de leurs utilisations le remplace par un autre service. Cette
du Cloud et donc avoir accès aux analyse nécessite la mise en place d’une
rapports de facturation pour politique d’étiquetage (tagging) des
comprendre les impacts de leurs ressources.
usages et les corriger,
— Les équipes doivent tirer avantage Une démarche FinOps à l’échelle de
des modèles de coûts variables l’entreprise peut par exemple aboutir à la
du Cloud (paiement à l’usage, réservation de capacités (VMs…). Sur AWS,
réservation de ressources). la réservation d’instances EC2 permet
par exemple de réduire les coûts de 72 %.
Ce même site publie annuellement un
rapport sur l’état du FinOps; ce rapport
montre que l’objectif principal aujourd’hui
d’une démarche FinOps est d’encourager
les équipes techniques à optimiser les
coûts en modifiant leurs utilisations des
services cloud.
VALEURS

02
16 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE
“CURRENTLY, DEVOPS IS
MORE LIKE A PHILOSOPHICAL
MOVEMENT, NOT YET A
PRECISE COLLECTION OF
PRACTICES, DESCRIPTIVE OR
PRESCRIPTIVE.”
Gene Kim,
auteur du livre The Phoenix Project

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 17

Les valeurs DevOps sont une extension Depuis, le modèle CAMS a été étendu en
des valeurs agiles qui encouragent la CALMS, L comme Lean, pour prendre aussi
collaboration entre équipes produit en compte des pratiques Lean : le Lean
et exploitants. Ainsi, pour réussir une management est l’optimisation de l’apport
transformation DevOps, l’entreprise doit de valeur aux clients en minimisant le
avoir mené sa transformation agile (ou gaspillage.
être en cours de la réaliser).
Le modèle CAMS a aussi été étendu en
John Willis et Damon Edwards ont résumé CALMR (R comme Recovery) pour gérer
(cf. article de blog sur la Culture DevOps) un élément essentiel pour l’exploitation :
les valeurs fondamentales DevOps dans le la reprise en cas de panne.
modèle CAMS défini par :
— Culture : créer une responsabilité Dans les chapitres suivants, nous
partagée entre les développeurs et aborderons quelques pratiques DevOps
les exploitants, courantes.

— Automation : automatiser les

processus pour les fiabiliser, les
accélérer, simplifier leur utilisation
et leur évolution,
— Measurement : mesurer la
satisfaction client ainsi que la
performance des équipes et
produits,
— Sharing : mettre en place
un système de partage de
connaissance entre les équipes
(documentation, travail en binôme,
retours d’expérience...).

18
01 YOU BUILD IT, YOU RUN IT

AFIN D’ACQUÉRIR UNE Dans les méthodologies agiles, cette

MEILLEURE COMPRÉHENSION
philosophie “You build it, You run it” prend
tout son sens : elle permet de construire

DES ENJEUX DE LA en parallèle le produit ainsi que le cadre

nécessaire à son exploitation.
PRODUCTION, L’ÉQUIPE
DEVOPS ESTIME QU’ELLE DOIT En revanche, dans une méthodologie
waterfall, cette manière de faire serait
ÊTRE RESPONSABLE DES moins pertinente : les équipes développent

CHOIX TECHNIQUES ET DE l’application puis livrent les informations

nécessaires (Dossier d’exploitation) aux
LEURS CONSÉQUENCES. exploitants qui construisent la plateforme
d’exploitation.

Ainsi, elle est responsable de la

construction du produit (le BUILD) et
de son MCO (Maintien en Condition
Opérationnelle).

Ceci permet aux développeurs de mieux

appréhender les contraintes de production
(pannes, performance, volumétrie des
données). Et, grâce à une collaboration
accrue avec les développeurs, les
exploitants acquièrent aussi une meilleure
vision du fonctionnement des applications.
Ceci les aide bien sûr dans leur mission
d’exploitation des services.
02 FAIL FAST. SUCCEED FASTER.

DANS L’ESPRIT DU LEAN Tant qu’une idée est en cours de test sur les
environnements de Hors Production, son
START-UP OU DES BOUCLES échec n’a pas réellement d’impact (sauf le

DE RÉTRO-INFORMATION temps consacré). À partir du moment où

le test est déployé en Production, il peut
(FEED-BACK) DE L’EXTREME y avoir de réels impacts sur les services

PROGRAMMING, LES déployés et sur les utilisateurs.

ÉQUIPES DOIVENT TESTER Pour limiter les impacts, il est prudent

RAPIDEMENT DES IDÉES ET de procéder par étapes : tester sur une

partie des utilisateurs ou sur une partie
DES TECHNOLOGIES. des services...

L’équipe doit aussi mettre en place des

Le concept du Fail Fast propose de tester
contrôles pour détecter les anomalies et
des idées en limitant au maximum les
des processus de rollback pour revenir à
conséquences de l’échec. Et quand
la version précédente.
une idée fonctionne, elle permet de
gagner en productivité, qualité de
service... (d’où le Succeed Faster).

Pour permettre l’émergence d’une culture

Fail Fast qui est très importante pour
l’innovation, l’organisation doit accepter
les erreurs tout en essayant de les limiter
au maximum.

20 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE

03 DÉSACRALISATION
DE LA PRODUCTION

LA PRODUCTION NE DOIT PAS La distance crée des appréhensions

sur une pratique très rarement mise
ÊTRE UN ESPACE SACRÉ QUI en œuvre. Nous l’avons tous entendu :

NÉCESSITE UN CÉRÉMONIAL “Ça marche, je n’y touche pas ! ”.

DE PLUSIEURS MOIS Le meilleur moyen de sortir de ces

POUR FAIRE LA MOINDRE méfiances naturelles est de se confronter

à la production en réalisant des mises en
ÉVOLUTION. production régulières.

21
04 DEVOPS EST AGILE

Si l’on considère que le besoin d’une La mise en production automatisée et

boucle de rétro-information (feedback) fait régulière est la conséquence directe de la
partie de l’agilité, que SCRUM demande de mise en place de l’agilité en entreprise.
livrer à l’issue de chaque sprint “un produit
susceptible d’être mis en production” et La valeur du manifeste qui prône la
que les pratiques DevOps permettent de communication apparaît également en lien
mettre automatiquement ce produit en direct avec le besoin de briser les barrières
production ; alors, la complémentarité des entre développeurs et exploitants.
deux mouvements apparaît facilement.

WATERFALL AGILE CONTINUOUS CONTINUOUS CONTINUOUS

INTEGRATION DEPLOYMENT OPERATIONS
CONTINUOUS
DELIVERY

22 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE

PROCESSUS

23
Un objectif important du DevOps est Les processus DevOps sont souvent
d’automatiser et d’industrialiser la chaîne représentés par le symbole “infini” (cf.
de production de manière à : figure ci-dessous). Ce symbole illustre le
— Réduire les délais de mise à fait que les équipes réalisent régulièrement
disposition des fonctionnalités aux des cycles complets de développement
utilisateurs (Time-to-Market), jusqu’au déploiement tout en exploitant
— Améliorer la qualité du produit, les services déployés.
— Améliorer l’efficacité des équipes.

24
01 INTÉGRATION CONTINUE

L’INTÉGRATION CONTINUE Chaque intégration de code est validée

par un processus automatisé qui construit
(CONTINUOUS INTEGRATION) les livrables du produit (notamment les

EST UNE MÉTHODOLOGIE RELEASE), exécute les tests, analyse la

qualité de code... Le processus remonte un
OÙ LES DÉVELOPPEURS feedback (rétro-information) aux équipes

INTÈGRENT LES concernées en cas d’erreur (mail, slack…).

MODIFICATIONS DE CODE
FRÉQUEMMENT DANS LE
RÉFÉRENTIEL DE CODE
SOURCE (GIT...).
FEEDBACK
UTILISATEUR

Dépôt de code Intégration Continue

COMMIT BUILD
TEST
QUALITY

Développeur

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 25

02 DISTRIBUTION
ET DÉPLOIEMENT CONTINU
La distribution continue (continuous delivery) est une pratique où le code est prêt à
être déployé en production, mais nécessite auparavant une validation (tests manuels
d’acceptance, coordination avec d’autres déploiements...).

Le déploiement continu (continuous deployment) consiste à déployer automatiquement

(sans approbation humaine) le nouveau code en production.

DEPLOY

Dépôt Intégration Environnement

COMMIT de code Continue cible

BUILD
TEST
Développeur
QUALITY

La mise en place du déploiement continu nécessite un certain nombre de garde-fous.

En voici quelques exemples :
— Déployer de petits changements pour réduire les risques (fonctionnalité par
fonctionnalité),
— Implémenter le Feature Flipping qui permet de remplacer à chaud une
implémentation d’une fonctionnalité par une ancienne implémentation (réputée
fiable),
— Implémenter des processus de déploiement progressifs qui déploient l’application
à un petit nombre d’utilisateurs et réalisent un retour arrière s'ils détectent des
erreurs.

26
Les exemples les plus connus d’entreprises Quel est le coût acceptable ? Comme nous
qui réalisent du déploiement en continu le verrons dans cette partie, les stratégies
(en production) sont des grandes de déploiement progressifs nécessitent
entreprises (AWS, Netflix...) qui conçoivent de l’outillage complexe, ainsi que plus de
des architectures microservices et ressources.
réalisent quotidiennement des nombres
impressionnants de mises en production Le choix d’une stratégie de déploiement
(plusieurs milliers pour AWS). implique aussi des contraintes.

Le déploiement continu permet à ces En effet, pour déployer une nouvelle

grands acteurs technologiques d’optimiser version d’un service sans rupture,
le Time-to-Market. Pour ces entreprises, les développeurs doivent gérer la
ne pas déployer en continu serait rétrocompatibilité des schémas de
synonyme de déploiement par lots de données : l’ancienne version du service
tailles importantes. Et ceci augmente la doit fonctionner avec le nouveau schéma
complexité à déterminer rapidement les de données.
origines des anomalies et à les corriger.
Si cette condition n’est pas respectée, deux
Au vu de la maturité nécessaire pour sa versions successives du service ne peuvent
réalisation industrielle, le déploiement pas fonctionner simultanément sur la
continu est souvent limité aux même base de données. Le processus
environnements de développement. Cette de déploiement doit donc, dans ce cas,
pratique permet aux développeurs de arrêter le service avant le déploiement
tester en continu leurs développements puis le démarrer après le déploiement.
sur un environnement iso-production.
Sans rétrocompatibilité, le retour arrière
sur un déploiement (ou ROLLBACK)
STRATÉGIES DE DÉPLOIEMENT impose aussi certaines contraintes comme
l’utilisation d’une image de la base de
données prise avant le déploiement avec
Le choix d’une stratégie de déploiement
le risque de perdre des données créées ou
dépend des contraintes des services
mises à jour après la création de l’image.
développés.

Quelle est la qualité de service attendue

(mémoire/CPU alloué...) ? Est-il acceptable
de réduire la qualité de service durant le
déploiement voire d’arrêter le service ?

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 27

1. BLUE/GREEN DEPLOYMENT

Le Blue/Green deployment permet de déployer une nouvelle version d’un service sans
rupture du service et sans impacter ses performances (i.e. conserver la même allocation
mémoire/CPU).

Ce modèle de déploiement impacte en revanche les ressources allouées pendant le

déploiement. En effet, le déploiement Blue/Green gère deux environnements : un
environnement Blue pour l’ancienne version du service et un environnement Green
pour la nouvelle version.

Environnement Blue
(version publiée)

Load Balancer

Environnement Green

Le “Blue/ Green deployment” est constitué par :

— Le déploiement de la nouvelle version sur l’environnement “Green” sans l’ouvrir
aux utilisateurs,
— La validation de l’environnement Green (tests automatiques, tests manuels,
supervision de l’application...),
— Si l’environnement se comporte correctement, ouvrir l’environnement Green aux
utilisateurs (et fermer l’ancien environnement) et supprimer l’environnement
Blue,
— Sinon, annuler le déploiement.

28
2. CANARY DEPLOYMENT

Le Canary Deployment permet de limiter le risque de déploiement d’une nouvelle version

en l’ouvrant progressivement aux utilisateurs.

10% des utilisateurs

Environnement N+1

Load Balancer

90% des utilisateurs Environnement N

Le “Canary deployment” est constitué des étapes suivantes :

— Le déploiement de la nouvelle version et l’ouvrir à une partie des utilisateurs,
— La validation de l’environnement Green (tests automatiques, tests manuels,
supervision de l’application...),
— Si la version se comporte correctement, ouvrir le service à une plus grande
proportion d’utilisateurs,
— Sinon annuler le déploiement.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 29

03 INFRASTRUCTURE AS CODE

L’INFRASTRUCTURE AS CODE — De simplifier la création de services

d’infrastructure (exemple : base
CONSISTE À MODÉLISER LES de données, vm...) en libre service

SERVICES D’INFRASTRUCTURE (catalogue de services).

(VM, BASES DE DONNÉES, La capacité de déployer rapidement de

DROITS...) PAR DU CODE nouveaux environnements a engendré

de nouvelles pratiques comme la création
(FICHIERS DE RESSOURCES d’environnements de test éphémères.

YAML, CODE DÉCLARATIF Cette gestion d’environnements

TERRAFORM...). éphémères s’intègre parfaitement au
processus de développement.

Cette pratique permet :

— D’accélérer le déploiement des
environnements et de s’assurer
que les déploiements sont
reproductibles,
— De gérer tous les environnements
de la même manière (tous
les environnements sont iso-
production) et donc d’éviter
les différences entre les
environnements,
— De simplifier le respect de règles
de gouvernance (exemple : tagging
des ressources) en développant
des modules d’infrastructure
réutilisables,

30
Voici un scénario d’utilisation des environnements éphémères :
— Quand un développeur démarre le traitement d’une User Story, il crée une
branche Git. Puis le job de CICD réagit à la création de la branche en déployant
le code dans un nouvel environnement dédié.
— Quand le développeur valide un changement dans GIT, la CICD le déploie
immédiatement sur l’environnement associé; ce qui permet au développeur de
tester son développement dans cet environnement (et non pas uniquement sur
son poste de développement).
— Quand le développeur finalise son développement, il crée une Merge Request
(MR). Et la personne qui valide la MR teste le développement dans l’environnement
associé.
— Finalement, quand la MR est validée, l’outil de gestion de code supprime la
branche de développement et le job de CICD réagit à la suppression de la branche
en détruisant l’environnement.

DEPLOY TEST
ENVIRONMENT

Dépôt Intégration Environnement

COMMIT de code Continue cible

BUILD VALIDATE
TEST
Développeur
QUALITY

Testeur

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 31

04 SUPERVISION
& OBSERVABILITÉ

Dans ce chapitre, nous aborderons deux Si par exemple, les temps de réponse
notions complémentaires : la supervision d’une API augmentent, les équipes sont
et l’observabilité. notifiées par une alarme et doivent
ensuite déterminer l’origine du problème
La supervision permet aux équipes et le corriger.
de détecter les anomalies/pannes du
système alors que l’observabilité permet Les équipes doivent définir leur stratégie
de comprendre l’état du système, de supervision :
comprendre son fonctionnement et bien — Quels sont les indicateurs à
sûr déterminer les sources des anomalies. superviser ?
— Quels sont les seuils/valeurs
critiques ?
SI VOUS NE POUVEZ PAS LE — Quels sont les niveaux de criticité ?

MESURER, VOUS NE POUVEZ Les SRE google ont construit et publié

PAS L’AMÉLIORER un ensemble de bonnes pratiques pour

LORD KELVIN, PHYSICIEN

la supervision d’application (cf. site web
Monitoring De Systèmes Distribués).

BRITANNIQUE DU 19E SIÈCLE.

1​. SUPERVISION

La supervision d’un système est l’activité

de collecte et d’affichage, en temps réel,
de données relatives au système. Cette
activité permet aux équipes de détecter
des anomalies du système.

32
Parmi ces bonnes pratiques, ils préconisent un suivi des 4 Signaux d’Or (4 Golden Signals)
— Latence : durée totale de traitement des requêtes,
— Traffic : mesure de la montée en charge du système (nombre de requêtes par
seconde),
— Errors : mesure du nombre de requêtes en erreur,
— Saturation : mesure de la saturation des ressources (pourcentage d’utilisation
du disque...).

Comme nous le verrons par la suite, il existe différents types de supervision.

La supervision d’infrastructure remonte des indicateurs sur l’état de santé des services
d’infrastructure (disponibilité, pourcentage d’utilisation du CPU/Disque/RAM... ).

La supervision applicative (Application Performance Monitoring ou APM) remonte des

métriques liées à la performance des applications (disponibilité, temps de réponse des
API, nombre de threads...).

Le Real User Monitoring (RUM) recueille, au niveau application, les métriques de

performance :
— Durée pour que les pages soient prêtes (page ready time),
— Durée de rendu des pages,
— Latence des requêtes.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 33

En réalisant les mesures au niveau de
2. OBSERVABILITÉ
l’application, le RUM est une mesure de
l’expérience utilisateur. Le RUM permet
aussi d’identifier, du point de vue de L’observabilité est une activité
l’utilisateur, des anomalies du système qui complémentaire à la supervision : c’est la
ne peuvent pas toujours être détectées par capacité de comprendre l’état interne du
les outils de supervision (car les anomalies système à partir de ce qu’il produit.
sont externes).
L’observabilité est construite sur 3 piliers :
La supervision fonctionnelle d’une les métriques, les logs, et les traces.
application consiste à collecter des
métriques “métier” de l’application.

Pour un site e-commerce, par exemple, Un outil d’observabilité important est l’outil
une métrique utile à suivre est le taux de de traçage des requêtes. En effet, il peut
transformation sur un pipeline de vente. construire, à partir d’un appel de service
Cette métrique doit être suivie de très près passé, le graphe complet des appels de
par l’équipe : tous les développements services engendrés.
réalisés doivent améliorer cette métrique
et toute détérioration notable de cette
métrique doit être étudiée et corrigée.

34
Ce graphe d’appel de services permet par exemple de comprendre la latence globale du
service et donc envisager des optimisations.

Dans le cas d’une anomalie sur un appel de services, l’outil de traçage permet de visualiser
le contexte de l’appel (en effet, l’anomalie arrive sur un appel de service qui fait partie
d’un traitement plus global) et de trouver une solution pour la corriger.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 35

OUTILS

04
36 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE
Bien qu’il soit intéressant de dissocier
intellectuellement les pratiques des
outils, il faut garder en mémoire qu’il y
a un enrichissement permanent entre
les outils et les pratiques : les outils
poussent de nouvelles pratiques qui
donnent naissance à de nouveaux outils.

Le but de ce document n’est pas de

faire une étude de ces outils, mais d’en
présenter quelques-uns qui répondent
aux besoins DevOps.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 37

01 GESTION DU CODE

LES OUTILS DE GESTION DE Voici quelques exemples d’outils :

CODE SONT CENTRAUX DANS Git est l’outil de gestion de code le

LES PROCESSUS DEVOPS. plus utilisé. Il existe de nombreux
sites Web (Gitlab, Github, bitbucket...)
qui simplifient son utilisation (fork,
Sur de nombreux sujets, le code est
pull request...) et fournissent de plus
devenu “source de vérité”. Les équipes
en plus de services annexes (qualité
gèrent, par exemple, les wikis en
de code, CICD, gestion des tâches...).
markdown, les schémas de migration SQL
en yaml (flyway, liquibase), les APIs REST
Pour illustrer le côté central du code
en yaml (OpenAPI), l’infrastructure par
dans les processus DevOps, le service
des fichiers de description de ressources
Gitlab s’est énormément transformé
(Cloudformation, terraform...).
et se décrit comme une plateforme
DevOps (et non plus comme une
Certains outils comme les outils d’analyse
application de gestion de code).
qualité (SonarQube) s’intègrent aussi
avec le gestionnaire de code. Ainsi, le
développeur qui réalise une revue de
code, trouve les annotations qualité sur le
code modifié ; ce qui est une excellente
aide pour la revue de code.

38
02 INTÉGRATION CONTINUE

LE SERVEUR D’INTÉGRATION CONTINUE (CI) EST LA PIERRE

ANGULAIRE DE L’AUTOMATISATION DES PROCESSUS.
Les Jobs d’Intégration Continue sont souvent découpés en étapes :
— BUILD :
- Exécution des tests unitaires
- Construction des artefacts,
— TEST : Exécution des tests d’intégration, des tests E2E,
— QUALITY : Analyse de la qualité du code,
— RELEASE : Versionning des artefacts,
— DEPLOY : Déploiement dans un environnement donné.

RELEASE
Dépôt Intégration Dépôts
de code Continue d’artefact

COMMIT BUILD
TEST
QUALITY GET VERSION

Développeur
Exploitant
DEPLOY Environnement
cible

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 39

Les solutions d’Intégration Continue Voici quelques exemples d’outils :
permettent de définir des processus
complexes avec des langages dédiés
Jenkins est depuis très longtemps
(exemple : jenkinsfile, Github actions...).
la solution CICD la plus déployée
en entreprise. Une des forces
En utilisant ces langages de modélisation
de Jenkins est son écosystème
de processus CICD, le développeur peut
extrêmement riche composé de
modéliser par exemple un processus qui
centaines de plugins (intégration
déclenche la création d’un environnement
avec de nombreux outils DevOps
à la création d’une branche Git. Cette
notamment).
pratique est poussée à l’extrême dans
l’approche GitOps où toutes les opérations
Gitlab CI est la solution CICD open
de déploiement sont déclenchées par des
source qui concurrence le plus
commandes Git.
Jenkins (qui est un peu vieillissant).
Son langage de description des
processus CICD ainsi que certains
points clés de son architecture
(intégration directe dans un
gestionnaire de code, les runners
gitlab pour l’exécution des Jobs) le
rendent très performant et agréable
à utiliser.

Bitrise est une CICD SAAS mobile qui

gère les serveurs de Build (MacOS
notamment) et l’outillage mobile
(SDK Android/iOS/Flutter/...).

AWS CodePipeline est le service

CICD d’AWS. CodePipeline
encourage les bonnes pratiques AWS
(exemple : déploiement Blue/Green
avec CodeDeploy sur AWS...) et
s’intègre très bien avec l’écosystème
AWS (gestion de code codecommit,
sécurité IAM, supervision
cloudwatch…).

40
1​. ANALYSE STATIQUE 2​. TEST

Les outils d’analyse statique permettent Les outils d’analyse statique permettent
de détecter des défauts dans le code : de détecter des défauts dans le code :
bugs, failles de sécurité (failles OWASP bugs, failles de sécurité (failles OWASP
notamment), code trop complexe notamment), code trop complexe
(exemple : méthode avec trop de (exemple : méthode avec trop de
paramètres, manque de structure du paramètres, manque de structure du
code...). code...).

Voici quelques exemples d’outils : La démarche de test d’une application a

été formalisée par Mike Cohn dans son
livre “Succeeding with Agile” (Cohn, 2010)
SonarQube est aujourd’hui l’outil le
en utilisant la métaphore de la pyramide :
plus utilisé pour l’analyse de code.
C’est un outil extensible (architecture — Implémenter un nombre suffisant
à base de plugins) qui gère un de tests unitaires (de manière
nombre impressionnant de langages à couvrir les fonctionnalités
et s’intègre avec de nombreux outils importantes),
CICD (Jenkins, Gitlab). — Un peu moins de tests d’intégration
(car plus coûteux à développer et à
Snyk est un nouveau concurrent de maintenir),
SonarQube capable d’analyser du — Et encore moins de tests d’IHM (car
code, des dépendances applicatives plus coûteux et moins fiables).
(npm, maven...), des images docker
ainsi que du code d’infrastructure
(terraform, kubernetes...). En plus
de remonter des vulnérabilités, Snyk
est capable de fournir un plan de UI
remédiation (proposer par exemple
la version à utiliser pour une
dépendance détectée vulnérable).
SERVICE

UNIT

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 41

Bien que cette vision pyramidale soit de
plus en plus remise en question (le test
Puppeteer est un outil
d’IHM est par exemple de plus en plus
d’automatisation des tests E2E pour
fiable et rapide), il reste important de
des applications Web. Une des forces
définir une stratégie de test adaptée à
de Puppeteer est d’exécuter les tests
l’application.
en pilotant un chrome headless (en
mode sans IHM) avec le protocole
Voici quelques exemples d’outils :
DevTools de Chrome.

Terratest permet de tester des Chaos Monkey, projet open source

ressources déployées avec un initialement développé par Netflix,
outil IAC. Un scénario de test permet de tester la résilience
consiste à déployer des ressources, d’applications aux pannes. Durant
vérifier certaines assertions sur les un test, les équipes vérifient le bon
ressources déployées (par exemple fonctionnement des applications
vérifier le bon fonctionnement d’un pendant que l’outil génère des
conteneur dans kubernetes), puis pannes aléatoires sur l’infrastructure.
supprimer les ressources déployées.
Initialement basé sur terraform,
l’outil permet aujourd’hui de tester
d’autres solutions IAC comme Docker
ou Kubernetes.

Gatling permet de réaliser des

tests de charge sur des applications
Web. L’objectif est de vérifier que
l’application se comporte bien dans
des conditions définies (nombre
d’utilisateurs cible avec des parcours
réalistes et une volumétrie de
données réaliste). Une des forces de
Gatling est le choix d’implémenter
les scénarios avec un DSL (langage
spécifique au domaine) basé sur le
langage de programmation Scala et
le framework asynchrone Akka.

42
3​. GESTION DES ARTEFACTS

Les processus de CI/CD gèrent le stockage des artefacts dans des dépôts (repositories
en anglais).

Pour prendre un exemple :

— Le processus BUILD construit et archive l’artefact dans un dépôt,
— Le processus DEPLOY télécharge l’artefact à partir du dépôt et le déploie.

L’utilisation de dépôts d’artefacts permet ainsi de supprimer le couplage entre les

processus de construction d’une application et son déploiement.

Les dépôts d’artefacts implémentent, en plus de la fonction de stockage, des fonctions

de sécurisation et de cache.

Pour détecter des failles de sécurité, les dépôts réalisent des scans de vulnérabilité
(notamment CVE) sur les packages stockés.

RELEASE

Dépôt Intégration Dépôts

de code Continue d’artefact

COMMIT BUILD
TEST
QUALITY

Développeur

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 43

Pour gérer l’intégrité des artefacts, ceux-ci Voici quelques exemples d’outils :
doivent être signés. La manière de signer
un artefact dépend de son type : Docker
Nexus Repository et JFrog
Content Trust permet de signer les
Artifactory sont deux dépôts
images Docker.
d’artefacts open source qui gèrent
les artefacts des langages de
Ensuite, l’utilisation des dépôts en tant que
programmation les plus courants,
cache permet d’éviter l’accès fréquent aux
des images docker, des packages
dépôts publics : ces accès peuvent être
linux (apt, rpm)...
lents et/ou onéreux. Docker Hub a depuis
2020, pour les comptes anonymes, une
Harbor est un dépôt d’image Docker
limite de 100 téléchargements d’images
“Kubernetes natif” qui implémente
par jour.
des fonctions :
- De stockage d’images Docker et
de charts Helm
- De sécurisation des images
Docker (scans de vulnérabilité,
signature)
- Et de synchronisation avec les
principales solutions concurrentes
(JFrog, ECR, GCR...); ce qui est très
pratique pour les entreprises qui
ont une stratégie multi Cloud.

44
03 DÉPLOIEMENT

LE DÉPLOIEMENT REGROUPE Voici quelques exemples d’outils :

DIFFÉRENTES ACTIVITÉS Terraform est aujourd’hui l’outil

COMME LE DÉPLOIEMENT Infra As Code le plus en vogue.

DE L’INFRASTRUCTURE, LA Le langage utilisé HCL (Hashicorp

Configuration Language) est
GESTION DE CONFIGURATION agréable à utiliser et bien géré par

(POUR DÉPLOYER DES les IDE. Cet outil prend en charge les
providers Clouds principaux (AWS,
SERVICES SUR DES VMS ET GCP, Azure...) ainsi que beaucoup

LES CONFIGURER) ET POUR

d’autres services y compris des
plateformes de virtualisation comme
TERMINER LE DÉPLOIEMENT VMware.

DES APPLICATIONS. Cloudformation est le service Infra

As Code managé d’AWS. Étant la
solution officielle AWS, ce service est
The Twelve-Factor App liste un
très bien intégré aux services AWS
ensemble de bonnes pratiques à suivre
(prise en charge par exemple rapide
pour le déploiement et l’exploitation
des nouvelles fonctionnalités AWS)
des services.
et encourage aussi le respect de
bonnes pratiques AWS. SAM est une
variante de Cloudformation pour les
1. DÉPLOIEMENT DE L’INFRASTRUCTURE architectures serverless.

Les outils d’Infrastructure As Code

permettent de déployer rapidement et
de manière fiable des environnements de
façon totalement automatisée.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 45

2. GESTION DE CONFIGURATION

Les outils de gestion de configuration

permettent d’automatiser des
tâches de gestion de serveurs :
installation et configuration de services
(exemple : serveur Web), déploiement de
fichiers...

Voici quelques exemples d’outils :

Ansible est un outil de gestion de

configuration python très utilisé.
Une des raisons de son succès est
son architecture qui ne nécessite pas
d’installer d’agents sur les machines
cibles. Cet outil est complété par
l’application Web AWX qui fournit
une interface Web, une API et une
solution d’orchestration des tâches.
Ansible Galaxy est un référentiel
de playbooks ansible open source
réutilisables.

Saltstack est aussi un outil de

gestion de configuration python.
Une de ses forces est sa conception
basée sur un bus de messages qui le
rend adapté à de très gros systèmes.
Salt gère un dépôt GIT de formules
Salt réutilisables.
3. DÉPLOIEMENT DES APPLICATIONS Voici quelques exemples d’outils :

Pour schématiser, un processus simple de AWS CodeDeploy est un outil AWS

déploiement d’une application peut être de déploiement qui permet de
vu comme un processus incrémental qui : déployer des applications sur des
— Sélectionne des VM à mettre à jour, VMs, des applications conteneurisées
— Déploie la nouvelle version de ainsi que des Lambda en gérant des
l’application sur ces VMs. déploiements progressifs (Blue/
Green, Canary).
Le déploiement se termine quand la
nouvelle version est déployée sur toutes FluxCD ou ArgoCD sont des solutions
les VMs. GitOps de déploiement natives
Kubernetes qui implémentent entre
Il existe deux grandes stratégies de autres des fonctions de déploiements
déploiement des applications. progressifs (Blue/Green, Canary). Les
déploiements sont réalisés avec des
La première, la plus ancienne, consiste à commandes Git. Ainsi pour déployer
scripter les déploiements dans une VM. du code dans un environnement, il
Cette stratégie simple à mettre en place suffit de le valider dans une branche
peut poser des problèmes : du même nom.

— Que faire, par exemple, si le script

de déploiement échoue avant
d’avoir terminé ? Dans quel état
sont les VMs ? Est-ce que le retour
arrière est simple ?
— Les scripts de déploiement sont
généralement testés dans des
conditions adaptées (VM qui
contient une version récente
de l’application). Comment être
sûr qu’un script de déploiement
fonctionne sur une ancienne VM ?

La seconde stratégie consiste à remplacer

la VM (ou conteneur Docker) par une VM
(ou image Docker) qui contient la nouvelle
version de l’application.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 47

04 SUPERVISION
& OBSERVABILITÉ
Voici quelques exemples d’outils :
POUR SUIVRE L’ÉTAT
DES SERVICES DÉPLOYÉS Grafana est une solution complète
de visualisation, d’analyse et de
(APPLICATIONS, SERVICES surveillance des métriques.

MANAGÉS, VMS...), LES Prometheus est une solution de

ÉQUIPES UTILISENT DES collecte des métriques et d’alerting

SOLUTIONS DE SUPERVISION
qui s’appuie sur une base de
données timeseries. Pour avoir

ET D’OBSERVABILITÉ. une belle visualisation des données

Prometheus, Prometheus s’intègre
comme source de données de
Grafana.

La Suite Elastic est une solution de

centralisation des logs basée sur
— Des agents (beats, logstash) de
remontée de logs et métriques
— Un cluster ElasticSearch pour
indexer et requêter les données
— Un kibana pour visualiser,
interroger et analyser les
données

Jaeger est un produit open

source de traçage des requêtes
développé initialement par Uber
Technologies. Jaeger permet entre
autres de visualiser les transactions
distribuées, d’analyser les latences
des requêtes.

48
05 SÉCURITÉ

LA MISE EN PLACE D’UNE

DÉMARCHE DE SÉCURITÉ
Falco est un produit open source
initialement développé par Sysdig,

CONSISTE À DÉTECTER AU qui permet de sécuriser et superviser

PLUS TÔT LES MENACES ET

des conteneurs docker. Falco permet
de suivre des comportements

LES TRAITER. inhabituels comme l’élévation

de privilèges, l’écriture dans des
répertoires système en lecture
La sécurité doit être gérée à la construction
seule (exemple /usr/bin), ou encore
des services (BUILD) et à leur exécution
l’exécution de commandes ssh...
(RUN). Il est utile d’appuyer la démarche
sécurité par des règles de gouvernance.
Cilium est un firewall pour
conteneurs. En plus de contrôler
Voici quelques exemples d’outils :
les flux entre Pods (ce qui est le
comportement par défaut du
Clair est un outil d’analyse firewall K8S), Cilium permet aussi
statique de vulnérabilités pour des d’appliquer des règles de filtrage de
images Docker. Pour détecter les niveaux IP, TCP et HTTP. Une règle
vulnérabilités, Clair s’appuie entre de niveau HTTP permet par exemple,
autres sur la base de données de en fonction de l’origine de l’appel,
vulnérabilités CVE. de filtrer les appels de services
autorisés par ressource REST et par
Kube-bench permet de vérifier verbe HTTP.
qu’un cluster Kubernetes respecte
les règles de sécurité définies dans le
Benchmark CIS pour Kubernetes.
Le CIS est un organisme à but non
lucratif qui aide les entreprises et les
gouvernements à se protéger des
cybermenaces.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 49

06 GOUVERNANCE

LES OUTILS Voici quelques exemples d’outils :

DE GOUVERNANCE AWS Config est un service

PERMETTENT DE VÉRIFIER d’inventaire des ressources AWS.

LA CONFORMITÉ DES AWS Config permet aussi de vérifier

la conformité des ressources par
RESSOURCES DÉPLOYÉES rapport à des règles définies et

AVEC DES POLITIQUES EN exécuter des actions de remédiation

sur les ressources non conformes.
VIGUEUR. UN EXEMPLE DE
POLITIQUE SOUVENT MISE EN Open Policy Agent (OPA) permet
de mettre en vigueur des politiques
VIGUEUR EST L’ÉTIQUETAGE (policy en anglais). OPA comporte

DES RESSOURCES (TAGGING)

un langage de modélisation des
politiques ainsi qu’une API. Ainsi,
UTILISÉ POUR LE SUIVI DE LA l’intégration d’OPA dans Kubernetes

FACTURATION.
(Gatekeeper) permet de mettre
en place des politiques comme
“interdire l’exécution de conteneurs
dockers issus de dépôts inconnus”
ORGANISATION
DES ÉQUIPES

05 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 51

DANS LA MISE EN PLACE Et trois types d’interactions entre les
équipes :
D’UNE DÉMARCHE DEVOPS, — La collaboration : les deux équipes

L’ORGANISATION collaborent,

DES ÉQUIPES EST

— La facilitation : une équipe aide et
mentore l’autre équipe,

FONDAMENTALE. — Et X-as-a-service : une équipe

fournit un service à l’autre équipe.

Ces aspects d’organisation sont Nous énumérons dans cette partie,

très bien décrits pour les équipes des exemples d’organisations DevOps
agiles dans le livre Team Topologies extraits de l’article DevOps Topologies.
(Skelton & Pais, 2019) puis déclinés Pour chaque type d’organisation, nous
pour les équipes DevOps dans l’article décrivons son mode de fonctionnement
DevOps Topologies. ainsi qu’un contexte où elle est pertinente.

D’après cet ouvrage, il existe quatre types

d’équipes :
— Stream aligned team : équipe
alignée sur un flux de valeur,
— Enabling team : équipe qui assiste
les Stream aligned teams (équipes
supports...),
— Complicated Subsystem : équipe
qui implémente un sous-système
complexe et qui nécessite un haut
niveau d’expertise,
— Platform team : équipe qui
fournit un produit aux Stream
aligned teams pour améliorer leur
productivité.

52
01 COLLABORATION
DEV ET OPS

DANS DES ENTREPRISES Voici quelques exemples de collaborations :

MATURES TECHNIQUEMENT,
— Les exploitants fournissent aux
équipes de développement des
LES ÉQUIPES DE consignes à respecter pour le

DÉVELOPPEMENT
déploiement des applications
(observabilité, sécurité...),

ET D’EXPLOITATION — Les équipes de développement

COLLABORENT DIRECTEMENT. aident les exploitants à développer

des bibliothèques de fonctions
C’EST LE MODE DE Infrastructure As Code réutilisables.

FONCTIONNEMENT “PAR
DÉFAUT” DEVOPS.

Dev Ops

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 53

02 OPS AS INFRASTRUCTURE-
AS-A-SERVICE

DANS DES ENTREPRISES OÙ Dans ce cas, l’équipe de développement

comporte une sous-équipe DevOps
L’IT RESTE TRADITIONNELLE, qui déploie et exploite les services en

IL PEUT ÊTRE INTÉRESSANT utilisant les ressources fournies (par

les exploitants). C’est cette équipe qui
D’AVOIR UNE ÉQUIPE collabore avec les exploitants.

D’EXPLOITANTS QUI AGIT

COMME UN FOURNISSEUR
DE RESSOURCES
D’INFRASTRUCTURE.

Dev DevOps Ops

54
03 DEVOPS-AS-A-SERVICE

DANS LES ENTREPRISES Pour éviter de créer un clivage entre les

équipes du client et celles du fournisseur
QUI NE PEUVENT PAS, POUR de service, il faut créer une relation de

DIFFÉRENTES RAISONS collaboration entre les deux équipes, ainsi

que des objectifs communs.
(TAILLE, COMPÉTENCES...),
PRENDRE EN CHARGE LES Cette organisation peut aussi être un
excellent moyen, pour l’entreprise, de
ACTIVITÉS D’EXPLOITATION, monter en compétences sur les sujets

IL PEUT ÊTRE INTÉRESSANT

DevOps, en observant une équipe experte
travailler.
DE LES SOUS-TRAITER À DES
FOURNISSEURS DE SERVICES.

Dev DevOps Ops

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 55

04 ÉQUIPE DEVOPS TEMPORAIRE

DANS DES ÉQUIPES MATURES L’objectif de cette équipe est d’apprendre

aux deux équipes à collaborer en
MAIS OÙ LA MISE EN PLACE apportant la culture DevOps.

D’UNE COLLABORATION DEV Quand c’est le cas, l’équipe DevOps

Temporaire perd de son utilité : il est
ET OPS SEMBLE RISQUÉE temps de la dissoudre pour la remplacer

(FRILOSITÉ DES ÉQUIPES), par une collaboration directe entre les

équipes produit et les exploitants.
IL EST POSSIBLE DE METTRE
EN PLACE UNE ÉQUIPE
DEVOPS TEMPORAIRE.

Dev DevOps Ops

56
TROIS
VOIES

06 ​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 57

DANS SON ARTICLE
DE BLOG THE THREE WAYS:
THE PRINCIPLES
UNDERPINNING DEVOPS
PUIS DANS SES LIVRES THE
PHOENIX PROJECT (BEHR ET
AL., 2018) ET THE DEVOPS
HANDBOOK (DEBOIS ET
AL., 2016), GENE KIM A
SCÉNARISÉ 3 VOIES DE MISE
EN PLACE DE PRATIQUES
DEVOPS.
La première voie est basée sur une
démarche Lean : elle consiste à partir
des flux de valeur, les automatiser (CICD,
infra as code...) et les optimiser. Dans le
Lean, un flux de valeur (ou Value Stream)
est l’ensemble des activités réalisées pour
délivrer un besoin qui apporte de la valeur
au client.

La deuxième voie est une démarche

d’amélioration continue basée sur une
boucle de rétroaction. Les équipes
observent le comportement du
système (métriques, log...), détectent
des anomalies (bugs, lenteurs...) et les
corrigent.

La troisième voie est celle de l’expertise

et de l’expérimentation. En se basant sur
leur expertise, les équipes consacrent du
temps pour améliorer l’existant.

58
01 PREMIÈRE VOIE

L’OBJECTIF DE LA PREMIÈRE La mise en place de cette voie repose

évidemment sur l’automatisation des
VOIE EST D’OPTIMISER processus :

GLOBALEMENT LES VALUE — Construction et validation des

STREAMS DU SYSTÈME :
livrables (exécution des tests
unitaires, analyse qualité du code),
— Déploiement des applications,
— Construction des environnements.
— Réduire le temps entre la prise en
compte d’un besoin d’un client et
sa livraison aux utilisateurs,
— Réduire les temps d’indisponibilité
du système.

L’optimisation doit être globale : il ne faut

donc pas optimiser localement les Value
Stream sans vérifier l’impact global.

business customer

DEV OPS

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 59

Mais pour dépasser cette première étape
nécessaire, l’entreprise doit avoir une
bonne vision des flux de valeurs ainsi
qu’une démarche pour les optimiser.

Cette vision peut être obtenue en

cartographiant les Value Stream par
Value Stream Mapping et en utilisant
cette cartographie pour identifier des
axes d’amélioration comme les goulets
d’étranglement (nombre de testeurs
insuffisants), ou le gaspillage (temps
d’attente entre équipes, travail non fini,
travail non nécessaire...).

Les pratiques agiles encouragent aussi

des pratiques d’organisation du travail
comme :
— Utiliser un outil de management
visuel (Kanban) pour rendre visible
le travail accompli,
— Limiter le nombre de tâches en
cours pour améliorer les délais de
livraison.

60
02 DEUXIÈME VOIE

L’OBJECTIF DE LA DEUXIÈME Pour illustrer le besoin de feedback, voici un

échange classique entre un Développeur et
VOIE EST DE METTRE EN un Exploitant :

PLACE UNE BOUCLE DE — Développeur : Mon déploiement est

RÉTROACTIONS RAPIDES
bon, il est passé sur l’environnement
de développement,

POUR VALIDER LE TRAVAIL — Exploitant : Certes, mais là tu as

ACCOMPLI ET DÉTECTER LES

déployé en production et ton
API utilise un index de base de

ERREURS OU ANOMALIES. données en cours de construction :

ton API retourne des codes 500.
Je dois donc faire un retour arrière
sur le déploiement et attendre la
fin de la création de l’index pour
redéployer.

DEV OPS

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 61

Après cet échange, la bonne pratique
apprise est que le processus de
déploiement doit séquencer les deux
déploiements : celui de l’index et celui
du code métier qui l’utilise. Pour éviter
de gérer à nouveau cette situation,
le développeur a ensuite modifié le
processus de déploiement pour exécuter
des tests avant déploiement (test de l’état
des index) : si les index sont en cours de
construction, le déploiement est arrêté.

Pour réaliser de manière efficace cette

boucle de rétroactions, il existe des bonnes
pratiques à mettre en place :
— Une base documentaire adaptée,
— Du peer review pour valider la
qualité des changements réalisés,
— Des tests d’acceptance du système,
— Des logs, des métriques et
des alarmes pour suivre le
comportement des services.

62
03 TROISIÈME VOIE

L’OBJECTIF DE CETTE Dans cette voie, les équipes sont

encouragées à expérimenter de nouvelles
TROISIÈME ET DERNIÈRE pratiques (code, architecture, services),

VOIE EST DE CRÉER UNE puis les généraliser à l’existant. C’est un

excellent moyen pour réduire la dette
CULTURE D’AMÉLIORATION technique.

CONTINUE BASÉE SUR Pour encourager cette pratique, il est

L’EXPÉRIMENTATION. important d’allouer du temps (exemple :
20 % du temps) aux équipes.

DEV OPS

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 63

METTRE EN
PLACE
UNE DÉMARCHE

07
DEVOPS

64
La démarche DevOps est un excellent
levier pour améliorer la qualité des
produits développés, la performance des
équipes ainsi que l’esprit de collaboration
et de responsabilité commune.

Pour initier la démarche, l’équipe

responsable de la transformation DevOps
définit les objectifs (cf. Objectifs, p66) et
évalue la maturité DevOps de l’organisation
(cf. Maturité DevOps, p67).

Ensuite, l’équipe construit une feuille de

route qui intègre des éléments structurants
comme les processus d’automatisation, le
suivi des indicateurs (cf. Élément clés, p71)
ainsi que des bonnes pratiques reconnues
(cf. Bonnes pratiques, p72).

COMME POUR TOUTE

TRANSFORMATION,
LA MISE EN PLACE DE LA
DÉMARCHE DEVOPS PEUT
COMPORTER CERTAINS
RISQUES.
NOUS EN DÉTAILLERONS
QUELQUES-UNS DANS LE
CHAPITRE LES RISQUES,
(P 79).

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 65

01 OBJECTIFS

LA MISE EN PLACE D’UNE Elle peut également être poussée par

des objectifs financiers comme le R.O.I
DÉMARCHE DEVOPS PEUT (Return On Investment - retour sur

ÊTRE MOTIVÉE PAR DES investissement) ou la gestion des coûts.

OBJECTIFS TRÈS DIFFÉRENTS. Dans une démarche d’amélioration

continue, il faut choisir, pour chaque
objectif, un indicateur et suivre son
Elle peut être guidée par des besoins des évolution.
clients :
— Accélérer l’apport de valeur aux
clients (Time-to-Market),
— Améliorer la qualité et la stabilité
des services développés.

Elle peut aussi être déclenchée par les

difficultés des équipes à réaliser leur
travail quotidien :
— Des déploiements complexes,
— Une trop grande dépendance
entre les équipes (nécessité de
se synchroniser avec d’autres
déploiements),
— Une difficulté à analyser et corriger
les anomalies des services.

66
02 MATURITÉ DEVOPS

L’ÉVALUATION DU NIVEAU L’évaluation permet aussi de définir

des axes d’amélioration et peut être
DE MATURITÉ DEVOPS utilisée comme base d’une démarche

PERMET DE VÉRIFIER QUE d’amélioration continue. En effet, en

évaluant régulièrement son niveau,
LES ÉQUIPES TROUVENT l’équipe détermine si elle s’améliore.

UN ÉQUILIBRE ENTRE LES Nous présenterons, dans ce chapitre,

PRATIQUES AGILES (QUI deux outils d’évaluation de maturité.

PERMETTENT AUX ÉQUIPES Le premier est développé par le framework

DE FOURNIR DE LA VALEUR Agile SAFe (cf. site web SAFe). En tant que

RAPIDEMENT AUX CLIENTS)

framework agile à l’échelle, SAFe gère la
mise en place de l’agilité au niveau de

ET LES BESOINS DE STABILITÉ l’entreprise en abordant par exemple

DES SYSTÈMES (OBJECTIF DES

des aspects comme la collaboration
entre équipes. SAFe est aujourd’hui le

EXPLOITANTS). framework agile à l’échelle le plus utilisé.

Le second est développé par le groupe

de recherche DORA DevOps Research
and Assessment (cf. site web DORA) qui
aide les entreprises à améliorer leurs
pratiques DevOps.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 67

1. SAFE

Pour évaluer son niveau de maturité, SAFe propose un questionnaire d’auto-évaluation

(cf. Outil d’évaluation SAFe). Le résultat est un radar similaire à la copie d’écran ci-dessous.

Les niveaux de maturité sont définis métaphoriquement par 5 types de mouvement du

plus lent au plus véloce : SIT (assis, niveau 0), CRAWL (rampe, niveau 1), WALK (marche,
niveau 2), RUN (cours, niveau 3) et FLY (vole, niveau 4).

Comme SAFe ne définit pas clairement les niveaux, il est intéressant de définir sa propre
interprétation. Voici un exemple :
— SIT : Build et Déploiement manuel,
— CRAWL : Build et Déploiement automatisé,
— WALK : Respect de règles “d’entreprise” (qualité, gouvernance, sécurité),
— RUN : Démarche d’amélioration continue,
— FLY : Déploiement en continu.

68
2. DORA

DORA propose aussi un questionnaire (cf. site Outil d’évaluation DORA) qui permet de
visualiser graphiquement sa maturité DevOps (cf. copie d’écran ci-dessous).

Le questionnaire définit 4 niveaux de maturité : Low (faible), Medium (moyen), High

(élevé), Elite (élite).

Ces 4 niveaux de maturité sont basés sur les métriques DORA (cf. DORA, p75) qui
mesurent le niveau d’agilité des équipes et le niveau de stabilité des systèmes construits :
— Une équipe peu mature (Low) est peu agile (fréquence faible de livraison) et le
système construit est peu fiable (temps de reprise de panne important),
— Une équipe très mature (Elite) est très agile (fréquence élevée de livraison) et le
système construit est très fiable (temps de reprise de panne faible).

L’outil permet aussi d’afficher son niveau par rapport aux autres entreprises du même
domaine.

L’outil propose aussi en fin de questionnaire des axes d’amélioration adaptés et très
bien documentés.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 69

Le groupe de recherche DORA publie aussi annuellement un rapport qui fait un statut
sur le DevOps. Ce rapport montre une progression rapide du niveau de maturité des
entreprises (7% d’entreprises Elite en 2018, 26 % en 2021).

70
03 ÉLÉMENTS CLÉS

NOUS AVONS DÉJÀ ABORDÉ Ensuite, comme expliqué par les trois
voies, l’organisation doit mettre en place
DANS CE DOCUMENT LES des processus :

ÉLÉMENTS CLÉS D’UNE

DÉMARCHE DEVOPS.
D’automatisation :
— Intégration continue,
— Déploiement (des applications et
de l’infrastructure),
Comme le DevOps est une extension de — Test des applications,
l’agilité, l’entreprise doit déjà avoir mis en
D’amélioration continue :
place une démarche agile ou être en train
— Mise en place de boucles de
de le faire.
rétroactions le long des flux de
valeur,
— Mise en place de référentiels de
bonnes pratiques,
— Supervision de la performance
des équipes et de la qualité des
services (exemple : métriques
DORA),
Et d’exploration :
— Test de nouveaux patterns
d’architecture et services,
— Impact de l’existant à partir des
nouveaux apprentissages.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 71

04 BONNES PRATIQUES

NOUS ABORDERONS DANS 1. DOCUMENTATION

CE CHAPITRE, QUELQUES
BONNES PRATIQUES À
Pour mettre en place une démarche
DevOps, les équipes doivent s’appuyer

SUIVRE POUR AUGMENTER sur une documentation de référence.

LES CHANCES DE SUCCÈS

Dans cette section, nous aborderons deux
sources d’informations importantes : SAFe

DE LA MISE EN PLACE DU et DORA.

DEVOPS. Au-delà de ces deux sources, un ouvrage

de référence à lire absolument est The
DevOps Handbook (Debois et al. 2016).
Pour se familiariser avec les enjeux et
apports de la démarche, il est important
de s’appuyer sur une documentation de
référence (cf. Documentation, p72).

Pour aligner les équipes sur les flux de

valeur, il faut commencer par les modéliser
(cf. Value stream mapping, p76).

Il est intéressant d’améliorer sa démarche

DevOps en travaillant aussi sur des aspects
techniques comme la conception basée
sur le modèle d’architecture microservices
(cf. Architectures microservices, p77) ou
la migration des applications vers le Cloud
(cf. Move to cloud, p78).

72
1.1 SAFE

Une des spécificités du framework SAFe est qu’il est très prescriptif et cette caractéristique
en fait une source d’information intéressante. En effet, comme illustré par la copie
d’écran ci-dessous, SAFe décrit le mode de fonctionnement des équipes (compétences,
processus...).

Sur les aspects DevOps, SAFe encourage par exemple la mise en place de processus
d’Intégration Continue, de Déploiement Continue, de Release On Demand (Versionning
des artefacts) et d’Exploration Continue (pour l’amélioration continue).

Comme illustré par le radar ci-dessous, SAFe découpe ces 4 processus en activités.
L’Intégration Continue comporte par exemple des activités de Développement, de Build,
de Test...

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 73

SAFe aborde aussi des aspects organisationnels comme la coordination des activités
des équipes (livraisons, test...) qui participent à un même flux de valeur, par un train de
livraison (Agile Release Train).

74
1.2 DORA

DORA propose des axes d’amélioration Les deux premières métriques mesurent
dans 4 thématiques (technique, processus, l’agilité des équipes, et les deux dernières
métrologie et culture) et propose pour mesurent la stabilité des services
chaque thématique des bonnes pratiques. développés.

Au sujet de la gestion du code, DORA La recommandation DORA est cohérente

recommande par exemple de suivre une avec la philosophie DevOps qui cherche un
démarche trunk based : les développeurs équilibre entre l’agilité des équipes et la
fusionnent quotidiennement leur code stabilité des services.
dans une branche commune à tous les
développements (la branche trunk). Cette L’amélioration d’une métrique a souvent
recommandation s’adresse notamment à des effets positifs sur les autres métriques :
des équipes expérimentées qui souhaitent une équipe qui augmente sa fréquence
mettre en place un déploiement continu. de déploiement (métrique Deployment
Frequency) améliore aussi la qualité des
Concernant l’amélioration continue déploiements (métrique Change Failure
des processus, le groupe de recherche Rate).
DORA recommande de contrôler les
changements avec les 4 métriques
suivantes :

— Deployment Frequency :
Fréquence de déploiement réussi
en production,
— Lead Time : Temps nécessaire
entre la validation du code jusqu’à
sa mise en production,
— Mean Time to Recovery : Temps
moyen d’une panne jusqu’à la
restauration complète du service,
— Change Failure Rate : Taux des
modifications du code qui ont
dégradé le système.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 75

2. VALUE STREAM MAPPING

Le Value stream mapping (VSM) est une pratique majeure dans la mise en place d’une
démarche DevOps.

En effet, comme illustré par le diagramme suivant (extrait du site Web SAFe), le VSM
permet de modéliser les étapes suivies de la définition d’une fonctionnalité jusqu’à sa
mise en production.

Un diagramme de flux de valeur peut être annoté par des informations utiles à son
analyse comme les durées des étapes ou les durées entre les étapes.

En tant qu’outil visuel, le VSM permet de partager la compréhension des flux de valeurs
entre équipes. Cette compréhension permet d’améliorer la qualité des livrables entre
équipes et réduire le gaspillage.

Le VSM permet de casser les silos : les équipes collaborent, indépendamment de la

structure de l’entreprise, pour améliorer la qualité de leurs livrables (réduction de la
dette technique, réduction du gaspillage...).

76
3. ARCHITECTURE MICROSERVICES

Les architectures microservices La mise en place d’architectures

(vs architectures monolithiques) sont microservices engendre aussi de la
particulièrement adaptées aux contextes complexité au niveau DevOps :
DevOps.
— Multiplication des processus
d’automatisation,
Ces architectures encouragent les équipes
à déployer régulièrement de petits — Complexité à interpréter les
changements. systèmes distribués,
— Complexité à gérer les
En effet, le développement d’applications environnements.
microservices simplifie :
Dans la conception d’architecture
— La validation des changements
microservices, pour éviter de gérer un trop
obtenus grâce à un contrôle des
grand nombre de services, de nombreux
impacts
retours d’expérience recommandent de
— Le déploiement indépendant (et se baser sur une conception pilotée par
potentiellement le retour arrière) domaine (DDD Domain Driven Design)
des services permis grâce à un et gérer le découpage des microservices
couplage faible entre les services par domaine (1 microservice = 1 domaine
(rétrocompatibilité des APIs, métier). La démarche DDD est décrite
architectures événementielles), dans le livre Domain-driven design (Evans
— La mise à l’échelle (scaling & Evans, 2004).
horizontal) des services grâce
à une gestion dynamique des
ressources (dimensionnement des
ressources déterminé en fonction
de la charge).

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 77

4. MOVE TO CLOUD

La migration vers le Cloud est aussi La panoplie des services Cloud permet
un facteur de succès pour les équipes aussi aux équipes de développement
DevOps. de choisir les services les plus adaptés.
Ceci a un un impact très positif sur les
L’utilisation de services managés permet temps de développement (notamment
aux exploitants de se consacrer sur les dans une démarche d’exploration où les
services métier. Par exemple, implémenter équipes testent des services similaires
des solutions de sauvegarde de données pour trouver le plus adapté).
ou de synchronisation de bases de

données est une tâche compliquée et très La migration vers le Cloud permet aussi
consommatrice en temps. À l’exception une gestion dynamique des ressources : ce
du cas où ces éléments sont des facteurs qui représente d’une part une économie
concurrentiels pour l’entreprise, il est et permet aussi aux équipes de mettre en
recommandé de déléguer ces tâches aux place des environnements adaptés à des
fournisseurs de services Cloud. besoins différents (environnements de
tests, tirs de performances, prototypes...).

78
05 LES RISQUES

DANS CE CHAPITRE, 1. REFUS DU CHANGEMENT

NOUS ÉNUMÉRERONS
CERTAINS RISQUES QUI
Le refus de changement d’organisation
(par exemple de suppression des silos) est

PEUVENT ARRIVER DURANT un risque réel. Certaines équipes peuvent

avoir peur du changement ou y voir une
LA MISE EN PLACE DE LA perte de leadership.

DÉMARCHE DEVOPS. Pour remédier à ce risque, il est

intéressant de réaliser la transformation
par incréments :
— Intégrer en priorité les équipes les
plus motivées,
— Expérimenter sur de petits
périmètres (Minimal Viable
Product ou MVP),
— Réaliser des retours d’expériences,
— Communiquer sur les réussites,
— Réaliser les actions de montées en
compétences.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 79

2. DÉGRADATION DES FLUX DE VALEUR 4. MANQUE DE MOYENS

A chaque modification d’un flux de valeur, La mise en place d’une démarche DevOps
il est nécessaire de s’assurer que les nécessite des moyens matériels et des
modifications réalisées ne dégradent ni outils adaptés.
la qualité des produits ni la fréquence de
livraison. Concernant, par exemple, la validation
des Merge Request (MR), une pratique
Modifier les processus existants sans intéressante est le déploiement des
suivi d’indicateurs est un vrai risque. En MR dans des environnements de test
effet, sans indicateurs, il est impossible éphémères. Ceci implique d’allouer
de s’assurer objectivement des apports suffisamment de ressources pour
positifs ou négatifs des changements. gérer ces environnements éphémères
(proportionnel au nombre de MR à valider).
En revanche, en mettant en place
des indicateurs pertinents (comme Dans le cas où les équipes gèrent les
les métriques DORA), il est possible ressources de manière dynamique, le
de s’assurer des apports positifs des coût supplémentaire est proportionnel
changements réalisés. à la durée de vie des environnements
éphémères (coût faible si la durée de vie
de ces environnements est faible).
3. MANQUE DE CULTURE DEVOPS
Dans le cas où les équipes gèrent les
ressources de manière statique (à éviter si
La mise en place de pratiques DevOps possible), le coût est bien plus important :
comme “You build it, You run it” change le coût est lié à la surallocation des
le travail des équipes et nécessite des ressources pour gérer ces environnements
changements culturels, organisationnels, éphémères.
de processus et d’outillages.

Pour accompagner les équipes dans ces

changements, il existe différents moyens :
mise en place de formations, intégration
d’experts dans les équipes, création de
référentiels de bonnes pratiques...

80
5. MANQUE D’ORGANISATION DEVOPS

Comme abordé dans la partie

Organisation des équipes, la mise en
place d’une démarche DevOps a des
impacts sur l’organisation des équipes.

Lors de la mise en place d’une collaboration

Dev et Ops, il est par exemple nécessaire
de définir des objectifs communs et
prévoir du temps pour la collaboration.

Les développeurs doivent avoir du temps

pour prendre en compte les consignes
des exploitants (exemple : observabilité,
sécurité...).

Et les exploitants doivent avoir du temps

pour la mise en place des services
nécessaires (exemple : développement ou
validation des composants d’Infrastructure
As Code réutilisables...).

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 81

CONCLUSIO

“UNE DESTINATION N’EST

JAMAIS UN LIEU,
MAIS UNE NOUVELLE FAÇON
DE VOIR LES CHOSES.”
Henry Miller, romancier et essayiste
américain du 19ème siècle
POURQUOI
METTRE EN PLACE
CES PRATIQUES ?

La culture DevOps encourage à comprendre

les flux de valeur de l’entreprise et à les
optimiser globalement. Cette réflexion
encourage à supprimer les silos entre les
équipes, à améliorer la qualité des produits
ainsi qu’à supprimer le gaspillage.

La mise en place des boucles de rétroaction

permet d’améliorer en continu les flux de
valeurs, d’accepter les erreurs, d’encourager
le travail collaboratif et le partage de
connaissances.

L’amélioration continue de la qualité de

code, de l’architecture, de l’utilisation des
services utilisés permet une généralisation
des bonnes pratiques et donc une réduction
importante de la dette technique.

Au-delà du besoin initial d’améliorer la

qualité des produits, cette démarche permet
d’améliorer l’empathie, la confiance et la
communication entre les différents acteurs
d’un projet.

​COMPRENDRE LE DEVOPS POUR LE METTRE EN ŒUVRE 83

​BIBLIOGRAPHIE
Behr, K., Kim, G., & Spafford, G. (2018). The Phoenix Project: A Novel about IT, DevOps,
and Helping Your Business Win. IT Revolution Press.

Biographie Patrick Debois. Personal website of Patrick Debois – JEDI - Just Enough
Documented Information Blog from https://www.jedi.be/bio/

Cohn, M. (2010). Succeeding with Agile: Software Development Using Scrum. Addison-
Wesley.

Debois, P., Humble, J., Kim, G., & Willis, J. (2016). The DevOps Handbook: How to Create
World-class Agility, Reliability, and Security in Technology Organizations. IT Revolution
Press.

DevOps Topologies from https://web.DevOpstopologies.com/

DORA. DevOps from https://www.DevOps-research.com/research.html

Evans, E. J., & Evans, E. (2004). Domain-driven design. Addison-Wesley.

Explore DORA's research program. DevOps from https://www.DevOps-research.com/

research.html#reports

Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software

Architectures. ICS UCI from https://www.ics.uci.edu/~fielding/pubs/dissertation/top.
htm

Kim, G., Willis, J., Debois, P., & Humble, J. (2016). The DevOps Handbook: How to Create
World-class Agility, Reliability, and Security in Technology Organizations. IT Revolution
Press.

Manifeste Agile. (2001). Manifeste pour le développement Agile de logiciels

from https://agilemanifesto.org/iso/fr/manifesto.html

Monitoring de systèmes distribués. https://sre.google/sre-book/monitoring-

distributed-systems
Outil d’évaluation DORA. DevOps
from https://www.DevOps-research.com/quickcheck.html

Outil d'évaluation SAFe. AgilityHealth

from https://agilityhealthradar.com/safe-DevOps-assessment

Royce, W. (1970). Managing the Development of Large Software Systems. Proceedings

of IEEE.

SAFe 5 for Lean Enterprises from https://www.scaledagileframework.com/

Site Reliability Engineering. Site Reliability Engineering: Google from https://sre.google/

Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology

Teams for Fast Flow. IT Revolution.

The Three Ways: The Principles Underpinning DevOps. IT

Revolution
from https://itrevolution.com/the-three-ways-principles-underpinning-DevOps/

Willis, J. (2012, May 1). Culture DevOps. IT Revolution

from https://itrevolution.com/DevOps-culture-part-1/

CRÉDITS PHOTOS
François Delauney
altamirafilm.co
unsplash.com
pixabay.com
agilityhealthradar.com
devops-research.com
scaledagileframework.com
CONTACTEZ-NOUS !
fr.ippon.tech
blog.ippon.fr
medium.com/ippon

[email protected]
+33 1 46 12 48 48
@ippontech