Comprendre DevOps

pour le mettre en oeuvre

Ch arles Sab o u rd in
Pierre Baillet

LIVRE BLANC
JUIN 2017
TA B L E D E S M A T I È R E S

1 Les auteurs 3
2 A propos d’Ippon technologies 5
2.1. Nos solutions 6
2.2. Nous contacter 7
3 Licence 9
5 Le mot de GEOFFRAY GRUEL, Directeur Général 11
4 Comprendre DevOps pour le mettre en œuvre : des valeurs ... 13
6 Présentation du livre blanc 15
7 Comprendre “DevOps” 17
7.1. Les Valeurs 17
7.2. Les Pratiques 21
7.3. Les Outils 24
8 Mettre en place une démarche DevOps dans son entreprise 31
8.1. Les axes de maturité 31
8.2. Les questions à se poser pour mettre en place DevOps 34
8.3. Remarques 35
9 Conclusion : pourquoi mettre en place ces pratiques 37
10 Remerciements 38
1 LES AUTEURS

Pierre Baillet a rejoint Ippon Technologies en 2015. Centrant

son expertise sur les architectures, le back-end et la production,
il s’intéresse aux outils “DevOps” et à leur implantation dans les
entreprises avec pour objectifs de simplifier le travail de tous.
Retrouvez ses articles de blog sur http://blog.ippon.fr/author/
pbaillet/ et sur son site personnel http://oct.zoy.org/.

Charles Sabourdin a rejoint Ippon Technologies en 2015.

Régulièrement en charge de problématiques d’architecture,
de sécurité et de production, il est architecte Java/DevOps.
Il travaille sur des missions Agile et de production, assistant
Direction, développeurs et opérationnels vers un but commun:
l’amélioration du processus de production et l’expérience
utilisateur.

Déc o u v r ez t o u s leurs art i c les sur blog.ippon.f r

D evox x BE 2015
Charles Sabourdin

D evox x 4Kids Ch ez IPP ON

Charles Sabourdin

L e Scraping, c’est ‘i n !
Pierre Baillet

Un peu de code, un peu d e w e b,

beaucoup de cadeaux – 3 p ar ti e s
Pierre Baillet

c om pre ndre De v O ps / 2
2 A P RO P O S D’ I P P O N T E C H N O LO G I E S
Ippon est un cabinet de conseil en technologies, créé en 2003 par
Stéphane Nomis, sportif de Haut-Niveau et un polytechnicien, avec
pour ambition de devenir leader sur les solutions Digitales, Cloud et Big
Data.

Ippon accompagne les entreprises dans le développement et la

transformation de leur système d’information avec des applications
performantes et des solutions robustes.

Ippon propose une offre de services à 360° pour répondre à

l’ensemble des besoins en innovation technologique : Conseil, Design,
Développement, Hébergement et Formation.

Nos équipes tirent le meilleur de la technologie pour transformer

rapidement les idées créatives de nos clients en services à haute valeur
ajoutée. Elles accompagnent à la fois les grands groupes (Axa, EDF,
Société Générale, LVMH,...) et les champions français de l’industrie
numérique (CDiscount, LesFurets.com, Aldebaran....) dans leurs
innovations.

Nous avons réalisé, en 2016, un chiffre d’affaires de 24 M€ en croissance

organique de 20%. Nous sommes aujourd’hui un groupe international
riche de plus de 300 consultants répartis en France, aux USA, en
Australie et au Maroc.

Parten aires de vo s pro j e ts E nd to end

V U L G AR I S AT I O N D E VO P S / 3
2.1. Nos solutions

Avec IPPON, DevOps devient une réalité pour votre entreprise. C’est
une équipe d’experts à vos côtés. Ippon vous conseille dans la mise en
place d’une organisation permettant des synergies vertueuses entre
vos dev et vos ops. Ippon vous apporte sa maîtrise des outils DevOps.

De nombreuses entreprises font confiance à Ippon pour accélérer le

Time To Market de leurs applications. Elles ont pu incuber leurs projets
chez Ippon, gagner plusieurs mois dans leurs projets de développement
et généraliser une démarche DevOps grâce à notre expertise.

UNE IDÉE, UN POC,

U N P R O D U I T. . .

   
idée lean conseil
startup POC

   
product projet par équipe
backlog itérations agile

    
projet conseil infogérance
run DevOps cloud

Vo s b eso i n s, n o s so l u t i o n s
2.2. Nous contacter

PAR I S
BORDEAUX
N AN T E S
LYO N

R I C H M O N D, VA
WA S H I N G T O N, D C
N E W-YO R K

MELBOURNE
M AR R AK E C H

www.ippon.fr/contact
[email protected]
blog.ippon.fr

+33 1 46 12 48 48
@ippontech

c om pre ndre De v O ps / 5
3 LICENCE
Ce document vous est fourni sous licence Creative Commons Attribution Share
Alike. Le texte ci-dessous est un résumé (et non pas un substitut) de la licence.

Vous êtes autorisé à :

-- Partager — copier, distribuer et communiquer le matériel par tous

moyens et sous tous formats
-- L’Offrant ne peut retirer les autorisations concédées par la licence tant
que vous appliquez les termes de cette licence.
-- Selon les conditions suivantes :

Attribution :

-- Vous devez créditer l’Œuvre, intégrer un lien vers la licence et indiquer

si des modifications ont été effectuées à l’Oeuvre. Vous devez indiquer ces
informations par tous les moyens raisonnables, sans toutefois suggérer
que l’Offrant vous soutient ou soutient la façon dont vous avez utilisé son
Oeuvre.
-- Pas d’Utilisation Commerciale — Vous n’êtes pas autorisé à faire
un usage commercial de cette Oeuvre, tout ou partie du matériel la
composant.
-- Pas de modifications — Dans le cas où vous effectuez un remix, que
vous transformez, ou créez à partir du matériel composant l’Oeuvre
originale, vous n’êtes pas autorisé à distribuer ou mettre à disposition
l’Oeuvre modifiée.
-- Pas de restrictions complémentaires — Vous n’êtes pas autorisé
à appliquer des conditions légales ou des mesures techniques qui
restreindraient légalement autrui à utiliser l’Oeuvre dans les conditions
décrites par la licence.

Notes :

-- Vous n’êtes pas dans l’obligation de respecter la licence pour les

éléments ou matériel appartenant au domaine public ou dans le cas où
l’utilisation que vous souhaitez faire est couverte par une exception.
-- Aucune garantie n’est donnée. Il se peut que la licence ne vous donne
pas toutes les permissions nécessaires pour votre utilisation. Par exemple,
certains droits comme les droits moraux, le droit des données personnelles
et le droit à l’image sont susceptibles de limiter votre utilisation.l’auteur
ou des auteurs.​

c om pre ndre De v O ps / 6
4 L E M O T D E G E O F F R AY G R U E L
-- Amazon déploie un nouveau composant en production toutes les 12
secondes,
-- Booking.com fait en moyenne 1 release par minute,
-- Netflix a besoin de 16 minutes entre un check-in de code en
développement et un déploiement cloud multi-région testé.

Passé le choc des chiffres des professionnels de l’Internet je fais l’amer constat
que malgré les initiatives multiples engagées depuis presque 5 ans par la
plupart de nos clients du CAC40, près d’un tiers d’entre eux continue à faire des
livraisons trimestrielles ou semestrielles à dates fixes (à la mode mainframe),
un autre tiers atteint un cycle mensuel à date variable et seulement un dernier
tiers et sur quelques projets isolés est capable de déployer quotidiennement. Et
aucun des clients CAC 40 d’Ippon ne fait de déploiement continu industrialisé.
Inversement nous travaillons aussi avec des startups (ou des spinoffs de
CAC40) qui elles ont atteint l’objectif. Tous ont pourtant des objectifs clairs
d’amélioration du Time To Market mais le principal écueil constaté sur ces
chantiers d’amélioration du cycle de livraison (maintenant appelé DevOps) est
l’angle d’attaque du projet qui s’est souvent résumé à de l’outillage :

-- remplacement de l’envoi de code par mail par un outil (véridique en

2013),
-- automatisation du cloud privé mais toujours un formulaire papier
à renseigner pour provisionner une VM pour respecter le process de
refacturation interne,
-- budgets engloutis dans le développement de Clouds internes “home
made” alors qu’une dizaine de solutions éditeurs ou open source sont
disponibles sur étagère.

Et par rebond ces chantiers d’outillage ont dans la plupart des cas supplanté des
projets de réorganisation et de conduite du changement qui auraient permis
très simplement de partager les objectifs d’amélioration du cycle des livraisons
entre le business, les devs et les ops, le fameux “DevOps”. Ce White-Paper va
vous éclairer sur les étapes clés d’une amélioration continue de votre cycle de
livraison en partant de la vision et des valeurs à partager avant de se pencher
sur les pratiques et les outils.
Je vous en souhaite une excellente lecture et reste à votre disposition pour
partager nos convictions et expertises,

Geoffray Gruel,
Directeur Général Ippon Technologies,
[email protected]

c om pre ndre De v O ps / 7
5 COMPRENDRE DEVOPS POUR LE
M E T T R E E N ΠU V R E : D E S VA L E U R S A U
S E R V I C E D E V O T R E D É V E L O P P E M E N T.

DES POSSIBILITÉ INFINIES

c om pre ndre De v O ps / 8
6 P R É S E N TAT I O N D U L I V R E B L A N C
Depuis les années 70, les entreprises cherchent à incorporer
l’informatique au sein de leurs processus, tout en essayant de ne pas
entrer dans le sujet. L’informatique est un moyen, une “commodity”
qui ne doit pas détourner les opérationnels “métier” de leurs tâches
principales.

L’informatique est souvent vu comme un mal nécessaire, et reste donc

en dehors de l’entreprise. Les logiciels sont réalisés par des équipes
externes recrutées ponctuellement. Mais ces prestataires vont et
viennent au fil des projets, laissant derrière eux des développements
dans des états divers à la charge d’une équipe réduite au maximum,
souvent constituée de prestataires d’autres sociétés.

Afin néanmoins de cadrer les développements nécessaires et de

permettre au mieux la séparation des responsabilités (separation of
concerns (SoC)), il y a eu la création de documents de mise en production,
standardisés, complets, épais…

Cela a abouti à plusieurs problèmes :

-- les développeurs
• perdaient du temps à produire des documents,
• n’avaient pas les réponses et la connaissance des besoins
de la production,
•
ne connaissaient pas l’utilisation “réelle” de leurs
développements.
-- les opérateurs,
• ne connaissaient pas le fonctionnement des applications
qu’ils opéraient,
• n’avaient pas les informations dont ils avaient besoin,
• n’avaient pas les fonctionnalités dont ils avaient besoin.
-- la vivacité des produits rendait progressivement la
documentation trop longue à produire et l’expertise difficile à
acquérir.

Cette réalité organisationnelle, souvent cadrée par des relations

contractuelles, crée au niveau de la production les mêmes relations

c om pre ndre De v O ps / 9
“juridiques défensives” entre développeurs et opérateurs qu’entre MOA
et développeurs, où l’objectif principal (mettre en place un service) reste
bloqué sur des relations contractuelles interminables.

Chacun reste campé sur sa posture, les développeurs critiquant les

opérateurs pour leur bureaucratie et leur frilosité, les opérateurs
critiquant les développeurs pour leur manque de considération et leur
versatilité.
En parallèle de ces considérations contractuelles et manageriales,
l’émergence des technologies de virtualisation (VM, Cloud,...),
l’accélération des besoins conjugués aux nouveaux objectifs de réduction
des coûts et l’évolution des méthodes de développement (en particulier
grâce à l’agilité) ont fortement impacté le métier de la production.
Enfin, l’arrivée sur le marché des nouveaux fournisseurs de services,
plateformes et infrastructures, ont commencé à faire glisser le marché
depuis les datacenters privés vers les clouds providers tels qu’on les
connaît aujourd’hui.

DevOps, dans la continuité du manifeste Agile, propose de faire tomber

les murs entre développeurs et opérateurs au profit de chacun et du
produit.

Il s’agit donc d’intégrer les nécessités de production aux produits tout

en fluidifiant les processus de mise en production et de mettre en place,
sur la production, les bonnes pratiques d’amélioration continue déjà en
œuvre sur le code.

c ompr endre DevOps / 10

7 COMPRENDRE “DEVOPS”
Il est intéressant de subdiviser “DevOps” en 3 catégories :
-- les valeurs de communication et d’engagement, directement
issues des valeurs d’agilité,
-- les pratiques abstraites et en conformité avec des objectifs
opérationnels,
-- les outils qui sont légion et qui, bien qu’ils influencent ces
pratiques, peuvent être interchangeables.

7.1. Les Valeurs

Il n’y a pas dans le “mouvement” DevOps de “manifeste” à proprement

parler, comme on peut en trouver pour l’agilité par exemple (http://
agilemanifesto.org/iso/fr/). Ces valeurs sont pour faire une synthèse des
comportements observés et de ce que nous pensons qu’il est nécessaire
de mettre en place.

c om pre ndre De v O ps / 11
 John Willis et Damon Edwards parlent de CAMS

(Culture, Automation, Measurement, Sharing) pour

décrire DevOps : une culture commune permet

le travail en commun de deux équipes ayant des

objectifs à court terme différents tout en ayant le

même but à long terme.

Au dessus de cette culture, on va s’appuyer sur des

outils pour automatiser l’ensemble

des procédures de travail.

Vient ens u i t e l a me s u r e , qu i p e r m e t à t o u s

d’évaluer l a sat i s fac t i o n de s clie n t s e t l e s

perform anc e s de c h aqu e é qu i p e d a n s t o u s le s

dom aines. E n fi n , o n par t ag e t o u s ce s r e t o u r s

d ’expérience e n t r e l e s é qu i pe s e t le s d é cid e u r s

a fin de recomme n c e r c e c yc l e e t l ’e n r ich ir, t o u t e n

redonn an t à l a c o mmu n au t é p o u r f a i r e

pr o g r e sse r l a mé t h o d e .

c ompr endre DevOps / 12

7.1.1. “Build IT, Run IT”

Afin de permettre une responsabilisation des développements, mais

aussi une meilleure compréhension des enjeux de la production,
l’équipe DevOps estime qu’il est nécessaire d’être responsable des
choix techniques et de leurs conséquences. C’est pourquoi, elle est en
charge du MCO (Maintien en Condition Opérationnelle) du produit.
Cela permet aux développeurs de mieux appréhender les contraintes
de production. Cela offre aux opérateurs une meilleure vision des
applicatifs et des fonctionnements normaux de ces derniers.

7.1.2. “2 pizzas teams”

“Si votre équipe ne peut être nourrie avec 2 pizzas, il faut faire deux
équipes.”
C’est une métaphore de Jeff Bezos, le fondateur d’Amazon.com. L’idée
derrière cette phrase devenue culte est que pour maintenir un niveau
optimal de performance, votre équipe doit être petite et autonome.
Seulement 2 pizzas pour nourrir toute l’équipe.

Bien entendu, c’est une image et non une règle. Cependant, maintenir
une organisation en petites équipes doit permettre d’assumer le niveau
d’autonomie requis pour garantir la responsabilité de bout en bout : du
code à la production. On retrouve les concepts de “task force” d’une
équipe focalisée sur un seul but : délivrer le meilleur produit, dans les
meilleurs délais.

7.1.3. “Fail Fast. Succeed Faster.”

Il est préconisé d’apprendre de ses erreurs, et pour cela de faire des

expérimentations. Dans l’esprit du Lean Start-Up ou des boucles
de rétro-information (feed-back) de l’extreme programming, il est
important de pouvoir tester rapidement des idées, des technologies,
afin d’apprendre les bons et les mauvais aspects de celles-ci. L’équipe
doit être en mesure de faire des choix éclairés en permanence.
Être en mesure de faire des expériences sur sa production peut paraître
irresponsable ou risqué, mais c’est dans l’optique de gains qu’il y a des
prises de risques.
Il est bien sûr indispensable de minimiser les risques en ayant mis en

c om pre ndre De v O ps / 13
place l’outillage nécessaire à une restauration rapide des configurations
avant l’expérimentation.
Il faut donc prévoir d’activer et désactiver des composants ou
fonctionnalités en fonction des besoins et des tests que l’on met en
oeuvre. Mais ici encore, ces fonctions automatisées qui permettent
d’assurer le MCO sont présentes pour permettre aux équipes DevOps
d’apprendre. Ces outils sont le garant permettant à celles-ci de
prendre des risques en continu, en minimisant l’impact d’une erreur, en
permettant un retour arrière très simple.

7.1.4. Désacralisation de la production

Comme dit précédemment, il faut pouvoir agir vite sur sa production. La

production ne doit plus être un espace sacré nécessitant un cérémonial
de plusieurs mois pour faire la moindre évolution. La distance crée la peur,
crée des appréhensions sur une pratique très rarement mise en oeuvre.
Nous l’avons tous entendu : “Ça marche, j’y touche pas ! ”. Le meilleur
moyen de sortir de ces méfiances naturelles est de faire des mises en
production régulièrement. De plus, la nature répétitive de l’opération
permet de mieux justifier les investissements d’automatisation. S’il n’est
pas nécessaire d’automatiser une opération que l’on fait une fois par an,
il est indispensable d’automatiser une opération hebdomadaire.
Votre production redevient la matière vivante de votre produit.

c ompr endre DevOps / 14

7.1.5. DevOps est AGILE

Si l’on considère que le besoin d’une boucle de rétro-information

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

DEVOPS MOVEMENT

Waterfall Agile Continuous Continuous Continuous Continuous

Integration Delivery Deployment Operations

7.2. Les Pratiques

Sur la base de ces valeurs, on veut modifier les pratiques pour atteindre
des objectifs clairs :

-- réduire les délais de mise en production (Reduce Time To

Market),
-- améliorer la qualité du produit,
-- améliorer l’efficacité des équipes.

c om pre ndre De v O ps / 15
Pour toutes ces pratiques, il s’agit avant tout d’automatiser et
d’industrialiser la mise en production.
Les pratiques DevOps sont assez claires. Le but d’avoir dissocié pratique
et outil est de souligner l’indépendance qui existe entre les outils et
les pratiques. Tel monsieur Jourdain, il est probable que vous ayez des
pratiques DevOps dans votre entreprise sans le savoir.

7.2.1. Infrastructure as code : environnements standardisés,

automatisation à tout prix

Afin d’offrir des environnements de test, de développement,

d’analyse de performance, pour un changement de composant, etc.,
les opérateurs mettent en place des outils d’automatisation, des
scripts, des modèles (templates), des superviseurs, etc. L’ensemble
de ces outils programmables n’est pas totalement du développement
ni rigoureusement de la production. Cela constitue néanmoins un
patrimoine important de votre entreprise et de sa productivité. C’est en
partie ce patrimoine que DevOps va développer.

Les fichiers de description JSON, pour des produits

comme Rancher, Amazon Web Service, Kubernetes
ou Openshift permettant de déployer rapidement
l’ensemble des composants d’un service, sont un
exemple extrême de cette “Infrastructure as code”.

7.2.2. Intégration et Déploiement continus

L’intégration continue est maintenant plutôt entrée dans les moeurs,

mais dans la plupart des entreprises, l’intégration continue s’arrête au
serveur d’Intégration Continue. La plupart des entreprises ont préféré
limiter ces automatisations à l’espace de développement, parfois aux
environnements d’intégration. Mais pour beaucoup, l’automatisation
s’arrête ici. Les portes de la production restent gardées par des Ops

c ompr endre DevOps / 16

garants d’une certaine stabilité.
Maintenant que tous ont vu la qualité issue de l’intégration continue,
que chacun a pris confiance dans la capacité du produit à passer en
production à la fin de chaque cycle, il est envisageable de créer le pont
entre code et production et d’évoluer vers le Déploiement continu.

7.2.3. Blue/Green deployment

De même que le code doit être écrit pour être testable, l’architecture
doit être prévue pour permettre le déploiement continu. Le “Blue/
Green deployment” consiste à pouvoir mettre en production la nouvelle
version “Blue” pendant une courte phase de recouvrement où l’ancienne
version “Green” est progressivement décommissionnée. Cette pratique,
qui permet les mises à jours sans perte de service, implique néanmoins
des architectures logicielles adaptées. Il est donc préférable d’avoir
des services sans état (stateless) ou de prévoir dans les couches de
persistance et de service la cohabitation de plusieurs versions de
l’application.

7.2.4. Partage des indicateurs

Les opérateurs utilisent depuis toujours des indicateurs techniques

pour superviser leurs fermes de serveurs. Ils suivent l’occupation des
disques, du processeur, etc.
Il est pertinent d’enrichir ces indicateurs d’informations métier
qui permettent de suivre l’activité du produit. Ceux-là permettent
d’extrapoler les évolutions du produit et de prioriser les actions à
prendre : par exemple, il est possible d’avoir le taux de transformation
sur tel ou tel pipeline de vente, ou bien le nombre de personnes qui sont
allées consulter la page “tarif” sans ensuite transformer.
Il est également nécessaire de permettre à toute l’équipe (ou les
équipes) d’avoir le même niveau d’information. C’est un élément clef
pour faciliter la communication.

7.2.5. A/B Testing

Dans le même esprit que le “Blue/Green deployment”, l’A/B testing

consiste à diriger une partie de ses utilisateurs vers une version “B”
différente de la version nominale “A” afin d’étudier l’impact de cette

c om pre ndre De v O ps / 17
version.
Cette pratique nécessite une architecture logicielle prévue pour cela, et
il est également nécessaire d’avoir un trafic important pour que l’étude
d’impact de la fonctionnalité soit pertinente.
Il est possible d’utiliser cette technique pour contrôler la verbosité de
ses services. Cela permet d’avoir un serveur très bavard tandis que les
autres produiront moins de logs.

7.2.6. Cattle no Pet (des serveurs d’élevage, pas des serveurs de

compagnie)

L’idée de traiter ses serveurs comme du bétail et non des animaux de

compagnie est très inhérente aux architectures de containers où les
serveurs ne sont pas destinés à être persistants. Ce qui signifie que vos
serveurs sont instanciés ponctuellement pour répondre à un besoin,
comme une forte charge par exemple, puis sont détruits pour libérer
leurs ressources pour d’autres services.
Il devient donc nécessaire de mettre en place des outils autour de ces
infrastructures pour assurer la persistance de données nécessaires à
ses services.

7.3. Les Outils

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 bilatéral
permanent entre les outils et les pratiques : les outils poussent de
nouvelles pratiques qui donnent naissance à de nouveaux outils.
L’outillage dans DevOps est, comme dans beaucoup de cas en
informatique, une question d’appréciation où des arguments plus ou
moins biaisés justifient le choix d’un produit vis-à-vis d’un autre. Il faut
dire que la nature extrêmement vivace du marché informatique induit
qu’un choix, quel qu’il soit, est rapidement (3-6 mois) rendu caduc par la
nouvelle version des produits étudiés.
Cela ne supprime pas le besoin de prendre des décisions, mais augmente
la nature volatile des analyses et le besoin permanent de mettre à jour
ses connaissances sur le domaine.
Le but de ce document n’est pas de faire une étude de ces produits,
mais de présenter quelques outils répondant aux besoins des pratiques
DevOps.

c ompr endre DevOps / 18

7.3.1. Gestion des sources

Les gestionnaires de versions de code sont la base de l’ensemble des

pratiques. Ils permettent d’assurer le suivi de modifications et la tenue
de l’ensemble des évolutions du produit. D’abord issus des logiques
de centralisation avec CVS puis SVN, ces systèmes sont devenus
décentralisés et ont transformé les pratiques (Mercurial puis Git). De
plus, le contrôle de plus en plus atomique de ces dépôts de source
permet une plus grande fluidité dans le suivi des variantes, l’application
et le suivi des correctifs.
L’utilisation de branches et d’étiquettes (“tags”) est indispensable pour
assurer une traçabilité des modifications, des essais et correctifs mis en
oeuvre.

Git est un logiciel de gestion de versions

décentralisé. C’est un logiciel libre créé par Linus
Torvalds, auteur du noyau Linux. Son succès est
associé au site d’hébergement GitHub qui favorise la
création de “fork” locaux pour permettre aux souches
de code d’avoir des évolutions indépendantes, tout
en autorisant des propositions de correctif.
Mercurial e st u n l o g i c i e l de g e s t io n d e ve r s i o n s
décentrali sé appar u pe u de t e m p s ava n t G i t .
Le créat e u r e t pr i n c i pal d éve lo p p e u r
de M e r c u r i al e s t Mat t M a ck a l l.

c om pre ndre De v O ps / 19
7.3.2. Gestion de l’intégration

Le serveur d’intégration est la pierre angulaire de l’automatisation

du déploiement. La définition de workflows et de conditionnement
de validation permet d’automatiser la compilation, de valider la non
régression et d’assurer ainsi une meilleure qualité logicielle. Le serveur
le plus répandu est “Jenkins” qui, couplé aux outils de SonarSource (par
exemple), permet d’assurer un suivi de la qualité du code et de maîtriser
la dette technique.

INTÉGRATION CONTINUE

c ompr endre DevOps / 20

 - Jenkins est un outil open source d’intégration

continue écrit en Java. Jenkins fonctionne dans un

conteneur de servlets ou en mode autonome avec son

propre serveur Web embarqué.

Il s’interface avec des systèmes de gestion de

versions tels que CVS, Git et Subversion, et exécute

des projets basés sur Ant, Gradle, SBT ou Maven

aussi bien que des scripts arbitraires en shell Unix ou

batch Windows.

Sa version 2, récemment annoncée permet un

pipeline de construction du produit,

facilitant le déploiement continu.

- Buildbot est un outil d’intégration continu qui

fournit un framework pour adapter l’intégration

continue à votre façon de builder et non l’inverse.

Plus difficile d’approche que Jenkins, il est plus

puissant une fois maîtrisé.

c om pre ndre De v O ps / 21
7.3.3. Gestion de librairies et d’images

Le produit compilé et versionné est mis à disposition dans des serveurs

“bibliothèques” ou “dépôts” qui permettent de garantir l’origine des
images ou librairies. Bien qu’utilisés pour les paquets natifs (packages
systèmes de type deb ou rpm par exemple), les mécanismes de
signature, qui garantissent l’origine et la non corruption des artefacts,
ne sont que très rarement utilisés dans la gestion des librairies Java.
Ces mécanismes sont en cours d’adoption en ce qui concerne les images
Docker (Docker Content Trust). L’automatisation de la mise en oeuvre
des environnements (production, intégration, développement…) tend à
rendre ces dépôts de plus en plus critiques.
La question de la sécurisation de ces bibliothèques ou paquets est une
question importante pour éviter des installations de bibliothèques
corrompues (“tainted”). Enfin, les dépôts jouent un rôle important de
cache des artefacts, économisant aux utilisateurs des accès vers des
dépôts publics chaque fois que nécessaire.

JFrog-Artifactory JFrog-Artifactory est un gestionnaire de dépôt, permettant

d’assurer la gestion, les versions et l’intégrité des artefacts
qu’il gère et expose.

Nexus Nexus est un autre gestionnaire de dépôt ayant à peu près les
mêmes fonctionnalités qu’Artifactory.

7.3.4. Gestion du provisioning et configuration

Les outils de configuration et de provisioning, outils emblématiques

DevOps, sont primordiaux pour assurer un provisioning automatisé
efficace. Ce sont les outils “d’infrastructure as code”.
Ils permettent de mettre en place un serveur de façon automatisée et
paramétrée dans des délais très courts. On peut également les utiliser
pour contrôler périodiquement l’état de serveurs, rétablissant une
configuration de référence et garantissant la conformité de celle-ci
avec les normes d’entreprise. Il est ainsi possible de mettre en place des
modèles (templates) de serveur ou d’architecture.
On retrouve ces modèles dans les fichiers de déploiement d’architecture
AWS, Kubernetes ou OpenShift. Il devient ainsi possible de déployer

compr endre DevOps / 22

des serveurs de façon totalement automatisée, pour des tests ou des
adaptations ponctuelles à la charge.

Ansible Ansible permet de décrire un ensemble d’opérations

d’installation et de configuration d’un serveur. Ces opérations
pourront être effectuées en parallèle sur un ensemble de
serveurs.

Chef / Puppet Chef/Puppet permettent de définir un état dans lequel doit

être un serveur. Un agent installé sur le serveur s’assurera de
façon régulière du maintien de ce serveur dans l’état défini.

Vagrant / Docker Vagrant/Docker permettent de construire des images pour

ces services de containers ou de virtualisation de manière
complètement scriptée. On assure ainsi une reproductibilité
plus facile des environnements (ou serveurs) et des tests sur
ces machines.

7.3.5. Gestion des disponibilités et monitoring des serveurs

La très forte diminution des coûts d’une machine, due entre autre aux
capacités de virtualisation et de mutualisation, ne supprime pas le besoin
de suivre les serveurs hôtes ou hébergés. Il est nécessaire de faire ce
suivi des ressources, car s’il devient possible de créer des serveurs
en fonction des besoins, il faut néanmoins valider la disponibilité des
ressources, le nettoyage des instances non utilisées, la mise à disposition
des espaces de stockage nécessaires, etc.

Nagios Nagios est un logiciel de supervision qui permet de superviser

les ressources ou services et d’effectuer des opérations,
généralement des remontées d’alerte, au passage de certains
seuils.

Monit Monit est un superviseur local qui peut relancer un service

en cas de défaillance de celui-ci.

c om pre ndre De v O ps / 23
7.3.6. Gestion des logs et des indicateurs

Comme annoncé précédemment, le nombre grandissant des serveurs

rend impossible une gestion manuelle ou au doigt mouillé des services.
Il est indispensable de mettre en place des indicateurs pertinents
d’utilisation. Les indicateurs fonctionnels et techniques doivent
cohabiter pour permettre aux opérateurs des services d’anticiper les
besoins de ressources et de prioriser les évolutions.
Les indicateurs ou tableaux de bord permettent de piloter le produit.

ELK Elasticsearch, Logstash & Kibana forment un trio gagnant

pour l’exploitation des logs et la création d’indicateurs.

Graylog Graylog se présente comme un ensemble d’outils plus

simple qu’ELK mais avec les mêmes objectifs de contrôle et
exploitation des logs.

7.3.7. Gestion des demandes

Bien qu’elle ne soit pas naturellement assimilée aux notions DevOps,

la gestion des demandes est un pré-requis à la bonne gestion des
évolutions fonctionnelles, à la maîtrise des correctifs et des priorisations
d’industrialisation. Il s’agit d’être en mesure de tracer et de suivre les
anomalies et expérimentations réalisées sur le produit.

JIRA JIRA d’Atlassian est une des bases de gestion de demandes

de référence aujourd’hui sur le marché.

Redmine Redmine est une autre base de gestion de demandes,

opensource et plus simple d’accès que JIRA.

c ompr endre DevOps / 24

8 METTRE EN PLACE UNE DÉMARCHE
DEVOPS DANS SON ENTREPRISE
Chaque entreprise étant différente, il n’y a pas de trajectoire unique.
Il convient donc d’identifier pour chaque contexte l’ensemble des
transformations à mener.
Afin de faciliter l’identification de celles-ci, nous avons réalisé une
matrice, dans l’esprit du modèle de maturité CMMI (Capability Maturity
Model Integration).
Il s’agit ici de regarder suivant certains axes présentés ci-dessous où se
trouve votre entreprise (ou vos équipes) afin de définir les pratiques
nécessaires à mettre en oeuvre.

8.1. Les axes de maturité

8.1.1. Compilation

Le processus de compilation est un processus maîtrisé, mais qui peut

nécessiter des besoins d’environnement spécifique (OS, versions
de bibliothèques, …). Pour pouvoir travailler par fonctionnalité sans
impacter les autres développements et maintenir une automatisation
acceptable, il est préférable d’avoir des processus de compilation/test/
déploiement sur des branches différentes dans des environnement
dédiés.

8.1.2. Test

L’importance des tests unitaires et d’acceptance n’est plus a démontrer,

et même s’il n’est pas nécessaire de faire du TDD (Test Driven
Developement), l’ingénierie des tests est un art à perfectionner pour
permettre de valider son produit dans des délais raisonnables et sur des
périmètres acceptables.
Le suivi de la couverture des tests est une opération obligatoire dans le
code du produit.

8.1.3. Déploiement

Le provisioning, le déploiement et la configuration automatisés sont

l’objectif technique DevOps.

c om pre ndre De v O ps / 25
8.1.4. Indicateurs

Les indicateurs doivent permettre à terme de piloter vos ressources

mais également de vous aider à détecter des schémas de comportement
et d’anticiper vos besoins. L’exploitation des informations de production
pour la construction des évolutions de votre produit est la clef d’un
développement agile et vertueux pour vos ressources.

8.1.5. Monitoring

Les serveurs et les services sur lesquels tournent vos déploiements

doivent être supervisés afin de connaître en permanence leur état et
de faire des relances automatiques. La résilience de l’architecture fait
partie aujourd’hui des exigences business quasi incontournables pour
des produits professionnels.

compr endre DevOps / 26

 Débutant Novice Intermédiaire Avancé Expert

Code & - identification de - Machine dédiée à la - dépôt de librairies, - suivi de configuration, - VM de compilation
Compilation
la procédure de compilation (usine logicielle), - cluster de compilation, - compilation continue de dédiée,
compilation, - Compilation automatisée. - compilation continue. différentes branches. - A/B testing.
- logiciel de gestion de
versions.

Test - test manuel. - test unitaire, - analyse de performance, - nombreux tests unitaires, - couverture de test
- test de non régression. - test fonctionnel - nombreux tests complète.
automatisé. fonctionnels,
- analyse des risques,
- tests de sécurité.
Déploiement - quelques scripts de - déploiement complètement - test automatisé au - déploiement en - déploiement en
déploiement. scripté. déploiement, production semi- production automatisé.
- déploiement automatisé automatisé,
dans un environnement - environnement
dédié, totalement standardisé
- environnement (paramétré).
standardisé (paramétré).
Indicateur - rapport outillé, - rapport isolé, - rapport historisé, - analyse des tendances, - analyse prédictive.
- rapport uniquement - rapport diffusé, - rapport croisé, - analyse croisée.
pour le testeur. - centralisation des logs. - analyse de rapport simple.

Monitoring / - pas de supervision (le cri - suivi de l’état des serveurs, - alerte technique (Mail/ - relance automatisée des - interruption de
Résilience
des utilisateurs). - relance manuelle des SMS), services, services automatisée
services, - alerte métier, - estimation des besoins. (Chaos Monkey).
- alerte technique (locale). - astreinte définie.

c om pre ndre De v O ps / 27
8.2. Les questions à se poser pour mettre en place DevOps

8.2.1. Les objectifs que l’on souhaite atteindre

Comme pour l’ensemble des projets que l’on souhaite mettre en

place en entreprise, il est nécessaire de penser aux objectifs que l’on
souhaite atteindre. Les objectifs financiers, comme le R.O.I (Return On
Investment - Retour sur investissement), sont les plus simples à calculer
et à mesurer, mais d’autres objectifs doivent être attendus. Le Time to
market (TTM), la stabilité, la scalabilité, la standardisation etc.
Chacun de ces objectifs doit être mesuré en amont de votre démarche
afin de pouvoir apprécier, avec vos équipes, votre amélioration. Il faut
bien entendu prioriser ces objectifs, pour ne pas se tromper.

8.2.2.La maturité

La question de la maturité de votre système d’information et de vos

équipes est le point de départ d’une démarche de mise en place de
pratiques DevOps. Il faut toujours initier un état de départ pour faire
évoluer votre structure et surtout connaître le chemin parcouru. Il n’est
pas nécessaire d’être exhaustif, mais un état de départ est un élément de
référence très utile à tout processus de changement.

8.2.3. Les risques

Il faut identifier les risques de la mise en place de ce type de pratique.

Ces risques, comme dans toute conduite du changement, se traduisent
généralement dans l’instabilité qui suit le changement. Mais il est
possible aussi que le “tout” code tende à supprimer la documentation ou
que vos équipes ne soient pas prêtes aux standardisations qui découlent
de ces démarches. C’est également valable pour vos équipes métiers.

8.2.4. Les “quick win”

Il est souvent intéressant de commencer petit, notamment en travaillant

sur l’axe autour de l’amélioration de la production. La première étape
consiste à mettre en place un rituel de correction des incidents et
d’amélioration de l’exploitabilité. Cela permet d’une part d’initier la

c ompr endre DevOps / 28

communication, et d’autre part d’initier les bonnes pratiques de qualité
et normalement de dégager du temps aux opérateurs pour qu’ils
intègrent les processus de développement.

8.3. Remarques

Avant de conclure, il y a plusieurs points d’attention qui ne sont

pas nécessairement directement DevOps, mais que nous estimons
nécessaire d’évoquer au sein de cette réflexion.

8.3.1. La sécurité

Les développements doivent intégrer les aspects liés à la sécurité. Les

opérateurs, de par leur expérience (piratage de serveurs, sites défigurés,
mots de passe brute-forcés...) que les développeurs n’ont pas forcément,
peuvent/doivent contribuer à cette démarche.
Ce travail collaboratif doit permettre de prendre en compte à sa juste
valeur l’effort à fournir pour assurer un niveau de sécurité suffisant.
Il y a de nombreux outils qui permettent de prendre en compte la
sécurité dans l’intégration continue. Cette usine permet de valider les
mises à jour des logiciels dans des délais acceptables avant leur mise en
production. Comme pour tout, il faut comprendre le risque et les enjeux
pour y apporter le bon niveau d’investissement. La relation dev/ops
permet ainsi d’intégrer plus facilement la sécurité au cycle d’évolution
de vos produits.

8.3.2. Les containers et micro-services

Les architectures microservices sont en vogue actuellement. L’utilisation

de containers est une réponse possible pour leur mise en oeuvre.
Beaucoup de DSI regardent donc logiquement vers Docker compose et
Swarm, Kubernetes et Rancher, Mesos et Marathon ou OpenShift pour
faciliter la fourniture rapide de services.

Ces architectures sont très intéressantes et peuvent apporter beaucoup

de bénéfices (productivité, élasticité optimale, TTM réduit, etc.). Il faut
cependant prendre en considération l’impact de ce type d’architecture au
sein de votre système d’information, car il s’agit d’une façon nouvelle de
répondre au besoin d’optimisation des ressources et de standardisation.

c om pre ndre De v O ps / 29
Il ne faut pas oublier que les GAFA1 ont mis un certain temps à arriver
au niveau de maturité qu’ils ont actuellement. Il faut également souvent
permettre aux équipes de digérer les nouveautés apportées par ces
architectures très prometteuses avant de pouvoir les mettre en place.

8.3.3. ITIL et ITSM

Bien qu’il soit tentant d’opposer DevOps et ITIL, il faut plutôt y voir une
forte complémentarité, dans la mesure où ITIL cherche à normaliser le
vocabulaire et les processus de mise en production que DevOps tend à
automatiser.

1GAFA: Google, Apple, Facebook, Amazon.

compr endre DevOps / 30

9 CONCLUSION : POURQUOI METTRE
E N P L A C E C E S P R AT I Q U E S
DevOps existe depuis bientôt 10 ans. C’est une culture d’amélioration
et d’industrialisation. Cette industrialisation est de plus en plus vitale
pour les entreprises qui cherchent à réduire leur Time to market et
souhaitent améliorer la qualité de leur production.

Les équipes de développement ont initiés cette démarche

d’industrialisation au moyen des Usines Logicielles, des méthodologie
Agile, d’une organisation au service des métier. C’est désormais aux
services de Production (les Ops) de s’approprier la démarche DevOps
et de poursuivre l’industrialisation des déploiements et l’utilisation
systématique du code pour piloter les Infrastructure.

Associer la démarche DevOps aux nouvelles technologies mises à

disposition (API / Orchestrateurs de container...) permet de rendre
Intelligente la production et d’apporter aux Ops de nombreuses
possibilités d’automatisation.

Les métiers ne seront que plus satisfaits en voyant se créer de

nouvelles voies de collaboration souhaitée avec les Dev, démultipliant
les synergies et les possibilités d’innovation dont seule les Startups
disposent intrinsèquement.

c om pre ndre De v O ps / 31
10 REMERCIEMENTS

Les auteurs tiennent à remercier l’ensemble des relecteurs pour

leurs suggestions bienveillantes et critiques, et en particulier
David Martin pour son œil toujours avisé.

V U L G AR I S AT I O N D E VO P S / 32
 PAR I S
BORDEAUX
N AN T E S
LYO N

R I C H M O N D, VA
WA S H I N G T O N, D C
N E W-YO R K

MELBOURNE
M AR R AK E C H

www.ippon.fr/contact
[email protected]
blog.ippon.fr

+33 1 46 12 48 48
@ippontech

c om pre ndre De v O ps / 33
 Découvrez aussi nos
au t re s re s s o urces
sur http://www.ip pon.fr/ressources/

c ompr endre DevOps / 34

c om pre ndre De v O ps / 35
 www.ippon.fr
blog.ippon.fr

Paris
Nantes
Bordeaux
Lyon
Washington, DC
Richmond, VA
New York, NY
Melbourne
Marrakech