DevOps pour les Nuls

2e dition limite IBM

. Introduction

DevOps (abrviation de dveloppement et oprations), l'instar de nombreuses nouvelles

approches, est souvent un mot la mode pour beaucoup de personnes. Tout le monde en parle,
mais tout le monde ne sait pas ce que c'est. De manire gnrale, DevOps est une approche qui
repose sur les principes Lean et Agile dans lesquels les responsables mtier avec les services de
dveloppement, des oprations et d'assurance qualit collaborent pour dlivrer le logiciel en
continu dans l'objectif de permettre l'entreprise de saisir plus rapidement les opportunits du
march et d'acclrer la prise en compte des retours clients. En effet, les applications d'entreprise
sont si diverses et composes de tant de technologies, bases de donnes, d'quipements
utilisateurs, etc., que seule une approche DevOps permet de grer avec succs toute cette
complexit. Cependant, les opinions sur son utilisation divergent.

Certains affirment que DevOps s'adresse aux professionnels uniquement. D'autres avancent qu'il
tourne autour du cloud. IBM propose une vue large et holistique et considre DevOps comme une
approche de livraison du logiciel oriente mtier : une approche qui porte une fonctionnalit
nouvelle ou une amlioration de l'ide jusqu' la mise en production, en fournissant de la valeur
mtier aux clients finals de manire efficace et en capturant les retours des utilisateurs de cette
nouvelle fonctionnalit. Pour ce faire, la participation de toutes les parties prenantes, bien au-del
des quipes de dveloppement ou des oprations, est indispensable. Une vritable approche
DevOps englobe les lignes mtier, les utilisateurs, les responsables, les partenaires, les
fournisseurs, etc.

II. Chapitre1 : Qu'est-ce que DevOps ?

Dans ce chapitre :

examen d'un besoin mtier de DevOps ;

recherche de valeur mtier dans DevOps ;
description des principes DevOps.

Changer les habitudes de travail est toujours compliqu et demande un certain investissement. En
consquence, lorsqu'une organisation adopte de nouvelles technologies, mthodologies ou
approches, cette adoption doit tre motive par un besoin mtier. Pour dvelopper une tude de
rentabilit l'adoption de DevOps, vous devez comprendre le besoin mtier associ. Ce chapitre
porte sur les fondamentaux ncessaires l'laboration de l'analyse du besoin.

II-A. Description du besoin mtier pour DevOPs

pour rsoudre les problmes mtier. L'intention peut tre de rsoudre des problmes mtier
internes (tels que crer un systme de gestion de la relation client plus performant) ou d'aider
leurs clients ou utilisateurs finals (en fournissant une nouvelle application mobile).

Cependant, de nombreuses organisations ne mnent pas bien leurs projets logiciels, et leurs
checs sont gnralement lis aux dfis inhrents au dveloppement et la livraison des logiciels.
Bien que la majorit des entreprises aient conscience que le dveloppement et la livraison des
logiciels sont des activits essentielles, une tude rcente d'IBM dans le secteur indique que
seulement 25 % d'entre elles ont le sentiment que leurs quipes sont efficaces. Ces checs dans la
ralisation se traduisent par des pertes d'opportunits commerciales.

Ces difficults sont amplifies par une volution majeure des types d'applications que les
entreprises doivent fournir, des systmes d'enregistrement aux systmes d'engagement.

Systmes d'enregistrement : les applications logicielles traditionnelles sont de

grands systmes qui fonctionnent comme des systmes d'enregistrement
contenant d'normes volumes de donnes et/ou de transactions, et qui sont
conus pour tre trs fiables et stables. Comme ces applications n'ont pas besoin
d'tre modifies frquemment, les entreprises peuvent satisfaire leurs clients ou
leurs propres besoins mtier en fournissant une ou deux nouvelles versions
majeures chaque anne.
Systmes d'engagement : avec l'avnement des communications mobiles et
l'volution des applications Web, les systmes d'enregistrement sont complts
par des systmes d'engagement auxquels les clients peuvent accder
directement et utiliser pour interagir avec l'entreprise. Ces applications doivent
tre simples utiliser, trs performantes et pouvoir tre modifies rapidement
pour rpondre l'volution des besoins des clients et des contraintes du march.

Comme les systmes d'engagement sont utiliss directement par les clients, l'exprience
utilisateur, la rapidit de livraison et l'agilit revtent une importance extrme. En d'autres termes,
ils ncessitent d'adopter une approche DevOps.

Les systmes d'engagement ne sont pas des systmes isols et ils sont souvent lis des
systmes d'enregistrement. Par consquent, lorsque les systmes d'engagement changent, les
systmes d'enregistrement doivent changer aussi. En fait, tout systme ncessitant une mise
disposition rapide des innovations requiert DevOps. Ces innovations sont issues principalement des
technologies mergentes, telles que le cloud computing, les applications mobiles, le Big Data et les
rseaux sociaux, qui peuvent concerner tous les types de systmes. Nous aborderons ces
technologies mergentes la lumire de DevOps dans les chapitres 4 et 5.

II-B. Identification de la valeur mtier de DevOps

DevOps applique les principes Agile et Lean l'ensemble de la chane logistique logicielle. Il permet
une entreprise d'optimiser la rapidit de livraison d'un produit ou d'un service, de l'ide initiale
la version en production, aux retours client et aux amliorations apportes en rponse ces
retours.

Comme DevOps amliore la manire dont une entreprise apporte de la valeur ses clients,
fournisseurs et partenaires, il constitue un processus mtier essentiel, et non une simple
fonctionnalit informatique.

DevOps gnre un retour sur investissement significatif dans trois domaines :

amlioration de l'exprience client ;

accroissement de la capacit innover ;
acclration du retour sur investissement.

Les sections suivantes portent sur ces trois domaines.

II-B-1. Amlioration de l'exprience client

L'amlioration de l'exprience client (diffrencie et engageante) permet de fidliser les clients et

d'accrotre les parts de march. Pour apporter cette exprience, une entreprise doit obtenir et
rpondre en continu aux retours client, ce qui ncessite des mcanismes pour recevoir ces
informations de toutes les parties prenantes impliques dans l'application logicielle dlivrer :
clients, secteurs d'activit, utilisateurs, fournisseurs, partenaires, etc.

Dans l'environnement actuel des systmes d'engagement (voir Description du besoin mtier pour
DevOps dans les pages prcdentes de ce chapitre), cette capacit ragir et s'adapter avec
agilit amliore l'exprience et la fidlit du client.

II-B-2. Accroissement de la capacit innover

Les organisations actuelles appliquent des approches Lean pour renforcer leur capacit innover.
Leurs objectifs visent rduire le gaspillage et la reprise de travail et ddier les ressources aux
activits plus forte valeur ajoute.

Les tests A-B sont un exemple de pratiques courantes dans l'approche Lean ; dans ce cas de
figure, des entreprises demandent un petit groupe d'utilisateurs de tester et d'valuer deux
versions logiciels ou plus, ayant des fonctionnalits diffrentes. Ensuite, celui qui fournit les
meilleures fonctionnalits est dploy vers tous les utilisateurs et la version rejete est annule.
Ces tests A-B sont ralistes uniquement avec des mcanismes efficaces et automatiss, tels que
ceux qu'offre DevOps.

II-B-3. Acclration de la production de valeur

L'acclration de la production de valeur implique de dvelopper une culture, des pratiques et une
automatisation afin de dlivrer les logiciels rapidement, efficacement et de manire fiable jusqu' la
mise en production. DevOps, adopt comme fonctionnalit mtier, apporte les outils et la culture
ncessaires la planification efficace, la prvisibilit et au succs des nouvelles versions
logicielles.

La dfinition de valeur change d'une entreprise l'autre, et mme d'un projet l'autre, mais
l'objectif de DevOps vise fournir cette valeur plus rapidement et plus efficacement.

II-C. Fonctionnement de DevOps

Le mouvement DevOps a produit divers principes qui ont volu dans le temps et qui continuent
d'voluer. Des fournisseurs de solutions, notamment IBM, ont dvelopp leurs propres variantes de
DevOps. Cependant, tous ces principes adoptent une approche holistique de DevOps, et les
organisations de toutes tailles peuvent les adopter. Ces principes sont les suivants :

dveloppement et test sur des systmes similaires ceux de la production ;

dploiement avec des processus rutilisables et fiables ;
surveillance et validation de la qualit oprationnelle ;
amplification des boucles de retour.

Ces principes sont expliqus plus en dtail dans les sections suivantes.

II-C-1. Dveloppement et test sur des systmes de type

production

Ce principe provient du concept shift left,de DevOps dans lequel les problmes de la production
sont traits en amont dans le cycle de vie de distribution de logiciel jusqu'au dveloppement (voir
l'illustration 1-1).
Illustration 1-1 : le concept Sift-left traite en amont les oprations dans le cycle de vie de
dveloppement

L'objectif vise permettre aux quipes de dveloppement et d'assurance qualit (QA) de

dvelopper et de tester l'application par rapport des systmes qui se comportent comme des
systmes de production afin de dterminer le comportement et les performances de l'application
avant son dploiement.

La premire excution de l'application sur un systme de type production doit intervenir le plus tt
possible dans le cycle de vie pour rsoudre deux problmes potentiels majeurs. Cela permet d'une
part de tester l'application dans un environnement similaire l'environnement de production rel
o l'application sera dploye, et d'autre part de tester et de valider les processus de mise en
production eux-mmes en amont.

Du point de vue du dveloppement, galement, ce principe est trs efficace. Il permet l'quipe
des oprations de dterminer en amont dans le cycle la manire dont se comportera son
environnent lors de la prise en charge de l'application, et de crer un environnement d'application
optimis.

II-C-2. Dploiement de processus rutilisables et fiables

Comme l'indique le terme, ce principe permet aux quipes de dveloppement et des oprations de
prendre en charge un processus de dveloppement de logiciel agile (ou au minimum itratif)
jusqu' la production. L'automatisation est essentielle pour crer des processus itratifs, frquents,
rutilisables et fiables. Par consquent, l'organisation doit crer un pipeline de livraison qui permet
le dploiement et les tests de manire automatise et en continu. Les pipelines de livraison sont
expliqus plus en dtail dans le chapitre 3.

Les dploiements frquents donnent galement la possibilit aux quipes de tester les processus
de dploiement eux-mmes et donc de rduire les risques d'chec de dploiement lors de la mise
en production.

II-C-3. Surveillance et validation de la qualit oprationnelle

En rgle gnrale, les organisations surveillent efficacement les applications et les systmes dans
l'environnement de production, car elles disposent des outils qui capturent les mesures des
systmes de production en temps rel. Mais elles les surveillent d'une manire isole et
dconnecte : ce principe place en amont la surveillance dans le cycle de vie en exigeant que les
tests automatiss soient excuts plus tt et plus frquemment dans le cycle de vie pour surveiller
les caractristiques fonctionnelles et non fonctionnelles de l'application. Lorsqu'une application est
dploye et teste, des mesures de qualit doivent tre captures et analyses. La surveillance
frquente permet d'tre alert en amont des problmes oprationnels et de qualit qui peuvent
apparatre dans l'environnement de production.
Ces mesures doivent tre captures dans un format comprhensible et utilisable par toutes les
parties prenantes.

II-C-4. Amplification des boucles de retour

L'un des objectifs de DevOps est de permettre aux organisations de ragir et de procder aux
modifications plus rapidement. Dans la livraison des logiciels, cet objectif suppose qu'une
organisation obtienne rapidement un retour et apprenne tout aussi rapidement de chaque action
qu'elle excute. Ce principe implique que les organisations crent des canaux de communication
pour que les parties prenantes puissent accder aux diffrents retours et agir en consquence.

Le dveloppement peut agir en ajustant ses plans de projet ou ses priorits.

La production peut agir en amliorant les environnements de production.
L'entreprise peut agir en modifiant les plans de mise en production des
nouvelles versions.

III. Chapitre 2 : Examen des fonctionnalits DevOps

Dans ce chapitre :

description de l'architecture de rfrence DevOps ;

quatre chemins d'adoption de DevOps.

Les fonctionnalits qui constituent DevOps sont un large ensemble qui couvre le cycle de vie de
distribution des logiciels. Le point partir duquel une organisation peut initier une dmarche
DevOps dpend de ses objectifs mtier les dfis qu'elle tente de relever et les insuffisances
qu'elle doit combler dans ses fonctionnalits de livraisons de logiciels.

Ce chapitre examine une architecture de rfrence DevOps et les diffrentes manires qui
permettent une entreprise d'entreprendre une dmarche DevOps.

III-A. Chemins d'adoption de DevOps

Une architecture de rfrence fournit un modle d'une solution prouve en utilisant un ensemble
de mthodes et fonctionnalits prfres. L'architecture de rfrence DevOps traite dans ce
chapitre, aide les utilisateurs accder et utiliser les instructions, les directives et d'autres
documents ncessaires afin de structurer et concevoir une plateforme DevOps qui s'adapte aux
personnes, processus et technologies (voir le chapitre 3).

Une architecture de rfrence peut fournir des fonctionnalits via divers composants. Chacune de
ces fonctionnalits peut tre couverte par un seul composant ou un groupe de composants
fonctionnant conjointement. Par consquent, vous pouvez voir l'architecture de rfrence DevOps,
reprsente dans l'illustration 2-1, du point de vue des principales fonctionnalits qu'elle est
suppose fournir. Au fur et mesure que l'architecture dfinie se concrtise, ces fonctionnalits
seront supportes par un groupe de personnes comptentes, de pratiques dfinies et d'outils
d'automatisation.
 Illustration 2-1 :
l'architecture de rfrence DevOps.

L'architecture de rfrence DevOps de l'illustration 2-1 propose les quatre groupes de chemins
d'adoption suivants :

Pilotage ;
Dveloppement/test ;
Dploiement ;
Opration.

Les sections suivantes du chapitre examinent en dtail ces chemins d'adoption.

III-B. Pilotage

Ce chemin d'adoption est constitu d'une seule pratique axe sur la dfinition des objectifs mtier
et leur ajustement en fonction des retours des clients : planification mtier continue.

Aujourd'hui, les entreprises doivent tre agiles et pouvoir ragir rapidement aux retours des
clients. La ralisation de cet objectif repose sur la capacit d'une organisation faire les choses de
manire juste et approprie. Malheureusement, les approches traditionnelles en matire de
livraison de logiciels sont trop lentes par rapport la vitesse actuelle du monde des affaires, en
partie parce que ces approches dpendent de processus de dveloppement personnaliss et
manuels, et que les quipes travaillent de manire isole en silos. Les informations requises pour
planifier et replanifier rapidement, tout en optimisant la capacit de fournir de la valeur, sont
gnralement fragmentes et incohrentes. Souvent, le retour d'utilisation pertinent n'est pas reu
suffisamment en amont pour atteindre le niveau de qualit appropri et la vritable valeur
fournir.

En outre, les quipes prouvent des difficults prendre en compte les retours susceptibles de
prioriser les investissements et du coup collaborer en tant qu'organisation capable de grer
correctement l'excution d'un modle de livraison continue. Certaines quipes considrent la
planification comme une tche de gouvernance intrusive qui les ralentit, et non pas comme une
activit qui leur permet de fournir de la valeur rapidement.

Une capacit dlivrer le logiciel plus rapidement rend l'entreprise plus agile, mais il faut
galement grer la vitesse avec l'assurance que ce qui sera dlivr correspondra ce qui tait
attendu. Vous ne pouvez distribuer rapidement des logiciels si vous ne croyez pas en la justesse de
vos objectifs mtier, vos mesures de suivi et d'analyse et votre infrastructure.

DevOps permet de rapprocher ces perspectives antagonistes en aidant les quipes dfinir
ensemble les objectifs mtier et les modifier en continu en fonction des retours de manire
amliorer la fois l'agilit et les rsultats d'entreprise. En parallle, les entreprises doivent grer
les cots. En identifiant et liminant les gaspillages dans le processus de dveloppement, les
quipes deviennent plus efficaces, mais amliorent galement les problmes de cot. Cette
approche permet aux quipes d'tablir un quilibre optimal entre tous ces points, dans toutes les
phases du cycle de vie DevOps vers un modle de distribution continue.

III-C. Dveloppement/test

Ce chemin d'adoption met en uvre deux pratiques : le dveloppement collaboratif et les tests
continus. Comme tel, il forme le cur des fonctionnalits de dveloppement et d'assurance qualit
(QA).

III-C-1. Dveloppement collaboratif

La distribution des logiciels dans une entreprise implique un grand nombre d'quipes
multifonctionnelles, des analystes mtier, des architectes d'entreprise et logiciels, des
dveloppeurs, des spcialistes Assurance-Qualit, des responsables des oprations, des experts en
scurit, des fournisseurs et des partenaires. Les utilisateurs de ces quipes travaillent sur
diffrentes plateformes et peuvent tre rpartis entre plusieurs sites. Le dveloppement collaboratif
leur permet de collaborer en fournissant un ensemble commun de pratiques et une plateforme
commune qu'ils peuvent utiliser pour crer et dlivrer les logiciels.

L'une des principales fonctionnalits dans le dveloppement collaboratif est l'intgration continue
(voir l'illustration 2-2), une pratique dans laquelle les dveloppeurs de logiciels intgrent en continu
ou frquemment leur travail celui des autres membres de l'quipe de dveloppement.

Illustration 2-2 : la collaboration via l'intgration continue.

L'intgration continue a t vulgarise par la mouvance Agile. Le concept consiste pour les
dveloppeurs intgrer leur travail celui des autres dveloppeurs de leur quipe, puis tester le
travail intgr. Dans le cas des systmes complexes constitus de plusieurs systmes ou services,
les dveloppeurs intgrent galement rgulirement leur travail d'autres systmes et services.
L'intgration rgulire du travail produit permet d'identifier et de rvler en amont les risques
d'intgration. Dans les systmes complexes, elle dvoile les risques connus et inconnus la fois
techniques et relatifs la planification.

III-C-2. Tests continus

L'intgration continue (voir la section prcdente) a plusieurs objectifs :

permettre les tests et la vrification continus du code ;

vrifier que le code produit et intgr celui des autres dveloppeurs et des
autres composants de l'application fonctionne et s'excute comme prvu ;
tester en continu l'application en cours de dveloppement.

Les tests continus impliquent de tester au plus tt et en continu tout au long du cycle de vie, ce qui
permet de rduire les cots, de raccourcir les phases de test et de disposer de retours en continu
sur la qualit. Ce processus, appel galement shift-left testing vise intgrer les activits de
dveloppement et de test pour que la qualit soit incorpore aussi tt que possible dans le cycle de
vie et non pas repousse une phase ultrieure. Cela est facilit par l'adoption de fonctionnalits
telles que l'automatisation des tests et la virtualisation des services. La virtualisation des services
est une nouvelle fonctionnalit de simulation des environnements de type production qui rend
possibles les tests continus.

III-D. Dploiement

Le chemin d'adoption Dploiement constitue la source des principales fonctionnalits de DevOps. La

livraison et le dploiement continus font passer le concept d'intgration continue l'tape suivante.
La pratique qui permet la livraison et le dploiement permet galement de crer un pipeline de
distribution (voir le chapitre 3). Ce pipeline facilite le dploiement continu des logiciels vers les
environnements d'assurance qualit, puis vers la production de manire automatise et efficace.
L'objectif de la livraison et du dploiement continus vise fournir aux clients et aux utilisateurs les
nouvelles fonctionnalits ds que possible.

La plupart des outils et des processus qui constituent le cur de la technologie DevOps existent
pour faciliter l'intgration, la livraison et le dploiement en continu. Ces points sont abords en
dtail dans les chapitres suivants.

III-E. Oprations

Le chemin d'adoption des oprations inclut deux pratiques qui permettent aux entreprises de
surveiller le fonctionnement des applications mises en production et d'avoir des retours clients. Ces
donnes permettent aux entreprises d'interagir avec agilit et de changer leurs plans mtier, si
ncessaire.

III-E-1. Surveillance continue

La surveillance continue fournit aux quipes des Oprations, d'Assurance-Qualit, de

Dveloppement, aux responsables de secteur et aux autres parties prenantes des donnes et des
mesures sur les applications diffrentes tapes du cycle de livraison.

Ces mesures ne sont pas limites la production. Elles permettent aux parties prenantes de ragir
en amliorant ou changeant les fonctionnalits dlivrer et/ou les plans mtier ncessaires.

III-E-2. Retours continus des clients et optimisation

Les deux types d'informations les plus importants que peut obtenir une quipe charge de la
livraison du logiciel sont la manire dont les utilisateurs utilisent l'application et leurs commentaires
sur son utilisation. Avec les nouvelles technologies, les entreprises peuvent capturer en temps rel
le comportement et les difficults des clients lors de l'utilisation de l'application. Les parties
prenantes peuvent s'appuyer sur ces retours afin de prendre les mesures appropries dans
l'objectif d'amliorer les applications et l'exprience des clients. Les responsables de secteur
peuvent revoir leurs plans, le dveloppement peut ajuster les fonctionnalits qu'il dcide de livrer
et le service des oprations peut amliorer l'environnement dans lequel l'application est dploye.
Cette boucle de retours continus est un composant essentiel de DevOps, puisqu'elle permet aux
entreprises d'tre plus agiles et ractives aux besoins des clients.
 IV. Chapitre 3 : Adoption de DevOps

Dans ce chapitre :

efficacit des individus ;

rationalisation des processus ;
choix des bons outils.

L'adoption d'une nouvelle fonctionnalit ncessite d'laborer un plan qui englobe les personnes, les
processus et les technologies. L'adoption de nouvelles fonctionnalits est voue l'chec
notamment dans une entreprise impliquant de nombreuses parties prenantes, potentiellement
rparties sans tenir compte de ces trois aspects adopter.

Ce chapitre porte sur les aspects DevOps lis aux personnes, aux processus et aux technologies.

Bien que le terme DevOpsfasse rfrence aux fonctionnalits de dveloppement et des oprations,
DevOps est une fonctionnalit d'entreprise qui englobe toutes les parties prenantes d'une
organisation, notamment, les mtiers, l'architecture, la conception, le dveloppement, l'assurance
qualit (QA), les oprations, la scurit, les partenaires et les fournisseurs. L'exclusion d'une de ces
parties prenantes internes ou externes se traduira par une implmentation incomplte de
DevOps.

IV-A. Savoir o commencer

Cette section explique comment dmarrer avec DevOps, notamment crer la culture approprie,
identifier les dfis conomiques et dterminer les goulots d'tranglement liminer.

IV-A-1. Identification des objectifs mtier

La premire tche de cration d'une culture consiste amener les personnes suivre la mme
direction et atteindre le mme objectif. Cela implique d'identifier les objectifs mtier communs
des quipes et de l'entreprise dans son ensemble. Il est plus important de rcompenser l'ensemble
de l'quipe en fonction des rsultats de l'entreprise plutt que des incitations d'quipe
conflictuelles. Lorsque les personnes connaissent l'objectif commun et savent comment
l'avancement de sa ralisation sera mesur, les dfis provenant des quipes et des utilisateurs
ayant leurs propres priorits sont moindres.

DevOps n'est pas un objectif. Il donne les moyens d'atteindre des objectifs.

Les chapitres 4 et 5 mettent en lumire plusieurs nouveaux dfis que DevOps permet de
surmonter. Votre entreprise peut utiliser ces dfis comme point de dpart pour identifier les
objectifs atteindre. Ensuite, elle peut dvelopper un ensemble de jalons communs vers l'atteinte
de ces objectifs l'intention des diffrentes quipes et parties prenantes.

IV-A-2. Identification des goulots d'tranglement dans le pipeline de

distribution

Les plus importantes sources d'inefficacits dans le pipeline de distribution peuvent tre regroupes
dans les catgories suivantes :

tches inutiles (avoir communiquer de manire rptitive les mmes

informations et connaissances) ;
reprise de travail inutile (dfauts non dtects lors des tests ou de la
production impliquant de raffecter le travail l'quipe de dveloppement) ;
surproduction (fonctionnalits dveloppes qui ne sont pas ncessaires).
L'un des principaux goulots d'tranglement dans le pipeline de distribution
est le dploiement de l'infrastructure. L'adoption de DevOps acclre la
 distribution des applications et impose l'infrastructure d'tre plus ractive.
Les environnements SDE (Software-Defined Environment) permettent de
capturer l'infrastructure comme un type de modle programmable et
rutilisable qui acclre de ce fait les dploiements. Consultez la section
L'infrastructure programmable dans les pages suivantes de ce chapitre
pour plus d'informations.

En outre, vous pouvez vouloir optimiser le pipeline avec un flux rgulier de bout en bout. Le
rythme de chaque processus doit tre identique pour viter les goulots d'tranglement. Pour
atteindre cet quilibre, vous devez instrumenter ou mesurer le pipeline de distribution des points
cls afin de rduire le temps d'attente dans les files d'attente, optimiser le travail en cours et
ajuster en permanence la capacit et le flux.

IV-B. Les individus dans DevOps

Cette section porte sur l'aspect humain de l'adoption de DevOps et la cration de la culture
ncessaire.

IV-B-1. La culture DevOps

l'origine, DevOps est un mouvement culturel ; il concerne les individus. Une organisation peut
adopter les processus ou les outils automatiss les plus efficaces possibles, mais sans les
personnes qui doivent excuter ces processus et utiliser ces outils, ils sont inutiles. La cration
d'une culture DevOps, par consquent, est au centre de l'adoption de DevOps.

Une culture DevOps se caractrise par un haut niveau de collaboration dans les rles, par une
concentration sur les objectifs de l'entreprise et non pas sur ceux de dpartements, sur la
confiance et l'importance que revt l'apprentissage par l'exprimentation.

La cration d'une culture DevOps ne revient pas adopter un processus ou un outil. Elle ncessite
(il n'y a pas de meilleur terme) une ingnierie sociale d'quipes d'individus ayant chacun des
prdispositions, des expriences et des dfauts. Cette diversit peut compliquer la cration d'une
culture.

Les pratiques de transformation Lean et Agile, telles que Scaled Agile Framework (SAFe),
Disciplined Agile Delivery (DAD) et Scrum, sont au cur de DevOps, et si votre organisation les
applique dj, vous pouvez les exploiter pour adopter une culture DevOps.

Mesure d'une culture

Mesurer une culture est extrmement compliqu. Comment pouvez-vous mesurer
prcisment l'amlioration de la collaboration ou l'tat d'esprit ? Vous pouvez mesurer
directement les attitudes et l'tat d'esprit des quipes en procdant des enqutes, mais ces
dernires peuvent avoir un fort taux d'erreurs statistiques, car gnralement les quipes sont
petites.
Inversement, vous pouvez mesurer indirectement en dterminant la frquence laquelle un
membre de l'quipe de dveloppement communique avec un membre de l'quipe des
oprations ou de l'quipe QA pour collaborer la rsolution d'un problme sans passer par
des canaux officiels ou diffrents niveaux hirarchiques.
Collaboration et communication entre les parties prenantes c'est bien la culture DevOps.

La cration d'une culture DevOps implique que les responsables de l'organisation collaborent avec
leurs quipes pour crer un environnement et une culture de collaboration et de partage. Les
responsables doivent liminer les barrires de coopration que les personnes rigent elles-mmes.
Les mesures standard permettent de fliciter les quipes des oprations pour le temps de
fonctionnement et la stabilit en production, et les dveloppeurs pour les nouvelles fonctionnalits
livres, mais elles dressent potentiellement ces groupes les uns contre les autres. Pour le service
des oprations, la meilleure protection est que l'quipe de production n'accepte pas les
modifications par exemple, et le service Dveloppement est peu enclin s'intresser aux
problmes de qualit. Remplacez ces mesures par une responsabilit partage pour fournir de
nouvelles fonctionnalits rapidement et en toute scurit.

Les responsables de l'organisation doivent, en outre, encourager la collaboration en amliorant la

visibilit. La cration d'un ensemble d'outils de collaboration communs est essentielle, notamment,
lorsque les quipes sont rparties gographiquement et ne peuvent pas se rencontrer
physiquement pour collaborer. Fournir toutes les parties prenantes la visibilit et l'tat d'un
projet est indispensable pour crer une culture DevOps base sur la confiance et la collaboration.

La cration d'une culture DevOps implique parfois que les individus changent. Il peut tre
ncessaire de changer de poste ceux qui sont rfractaires au changement savoir l'adoption
de la culture DevOps.

IV-B-2. L'quipe DevOps

Les arguments pour et contre l'existence d'une quipe DevOps distincte sont aussi vieux que le
concept lui-mme. Certaines organisations, telles que Netflix, ne disposent pas d'quipes
Dveloppement et Oprations ; une seule quipe NoOps est responsable de ces deux activits.
D'autres organisations ont mis en place avec succs des quipes de liaison DevOps qui rsolvent
les conflits ventuels et promeuvent la collaboration. Une telle quipe peut tre un groupe d'outils
ou de processus existants ou bien une nouvelle quipe constitue par des reprsentants de toutes
les quipes ayant un intrt dans l'application fournir.

Si vous dcidez de crer une quipe DevOps, votre principal objectif vise la faire fonctionner
comme centre d'excellence qui facilite la collaboration sans ajouter de la bureaucratie ou qu'elle ne
devienne l'quipe ddie la rsolution de tous les problmes DevOps une volution qui irait
l'encontre de l'adoption d'une culture DevOps.

IV-C. Le processus dans DevOps

Dans la section prcdente, nous avons vu le rle des individus et de la culture dans l'adoption de
DevOps. Les processus dfinissent ce que font ces personnes. Votre organisation peut avoir
instaur une culture efficace de collaboration, mais si les individus font ce qu'elles font, les bonnes
et les mauvaises choses, mais de la mauvaise manire, il existe une probabilit d'chec.

Un grand nombre de processus sont identifis avec DevOps ils sont trop nombreux pour tre
couverts dans ce manuel. Cette section porte sur les principaux processus la lumire de leur
adoption dans l'entreprise.

IV-C-1. DevOps comme processus mtier

DevOps comme fonctionnalit a un effet sur toute l'entreprise. Elle accrot l'agilit de l'entreprise et
amliore la livraison des fonctionnalits aux utilisateurs. Vous pouvez largir le champ de DevOps
en l'apparentant un processus mtier :un ensemble d'activits ou de tches qui produisent un
rsultat donn (service ou produit) pour les clients.

Dans l'architecture de rfrence prsente dans le chapitre 2, le processus mtier DevOps implique
de se saisir des fonctionnalits, de l'ide (gnralement identifie avec les propritaires du mtier)
jusqu' la production en passant par le dveloppement et les tests.

Bien que ce processus ne soit pas suffisamment mature pour tre captur dans un ensemble de
flux de processus simples, vous devez capturer les flux de processus que votre organisation utilise
dj pour fournir les fonctionnalits. Ensuite, vous pouvez identifier les domaines d'amlioration en
renforant les processus eux-mmes et en introduisant l'automatisation (voir la section Les
technologies dans DevOps dans les pages suivantes de ce chapitre).

IV-C-2. Processus de gestion des changements

La gestion des changements est un ensemble d'activits qui consistent contrler, grer et suivre
les changements en identifiant les produits de travail qui sont susceptibles de changer, et les
processus utiliss pour implmenter le changement. Le processus de gestion des changements
qu'utilise une organisation est une partie inhrente du flux plus vaste de processus de DevOps. La
gestion des changements dtermine la manire dont les processus DevOps absorbent et rgissent
aux demandes de modification et aux retours des clients.

Les organisations qui ont adopt la gestion du cycle de vie d'application (ALM) disposent dj de
processus bien dfinis et (probablement) automatiss de gestion des changements.

La gestion des changements doit inclure des processus qui offrent les fonctionnalits suivantes :

gestion des lments de travail ;

cycles de vie des lments de travail configurables ;
gestion de configuration logicielle ;
planification (agile et itrative) ;
contrle d'accs aux artefacts bas sur les rles.

La gestion traditionnelle des changements tend se rduire la gestion des demandes ou des
dfauts, avec une capacit limite suivre les vnements entre les demandes de changement ou
les dfauts et le code ou les exigences associs. Ces approches ne fournissent pas une gestion
intgre des lments de travail dans le cycle de vie ni une fonctionnalit intgre de suivi de tous
les types de donnes. Cependant, DevOps implique que toutes les parties prenantes puissent avoir
une visibilit et collaborer sur tous les changements dans le cycle de vie du dveloppement logiciel.

Une gestion des changements oriente DevOps ou ALM inclut des processus qui permettent de
grer tous les lments de travail de tous les projets, tches et donnes associes et pas
simplement ceux affects par une demande de changement ou des dfauts. Il inclut galement des
processus qui permettent l'entreprise de lier les lments de travail tous les artefacts, actifs de
projet et autres lments de travail crs, modifis, rfrencs ou supprims par les utilisateurs
qui travaillent dessus. Ces processus fournissent aux membres de l'quipe un accs base de rles
toutes les informations de changement et prennent en charge les efforts de dveloppement de
projet interactif et agile.

IV-C-3. Techniques DevOps

L'adoption de DevOps implique d'inclure un certain nombre de techniques parmi lesquelles :

Amlioration continue ;
Planification des versions ;
Intgration continue ;
Livraison continue ;
Test continus ;
Surveillance et retours continus.

Ces techniques sont examines en dtail dans la section suivante.

IV-C-3-a. Amlioration continue

Dans une vision Lean, l'adoption du processus n'est pas une action ponctuelle ; il s'agit d'un
processus qui volue en permanence. Une entreprise doit disposer de processus intgrs qui
identifient les domaines d'amlioration au fur et mesure que l'organisation devient plus mature et
qu'elle apprend des processus qu'elle a adopts. La plupart des entreprises possdent des quipes
ddies l'amlioration des processus, qui s'attachent amliorer les processus en fonction des
observations et des leons apprises. D'autres permettent aux quipes qui adoptent les processus
d'valuer et de dterminer elles-mmes leurs propres procdures d'amlioration des processus.
Quelle que soit la mthode utilise, l'objectif vise instaurer l'amlioration continue.
 IV-C-3-b. Planification des versions

La planification des versions est une fonction mtier essentielle qui repose sur la ncessit pour
l'entreprise d'offrir des fonctionnalits aux clients et sur les dlais de satisfaction de ce besoin. Par
consquent, les entreprises ont besoin de mettre en place des processus bien dfinis de
planification et de gestion des versions qui permettent d'instaurer des feuilles de route de sorties
de versions, des plans de projet, des planifications de livraison et une traabilit de bout en bout
dans ces processus.La plupart des entreprises actuelles excutent cette tche en utilisant des
feuilles de calcul et en tenant des runions (souvent trs longues) avec toutes les parties prenantes
de l'entreprise pour suivre toutes les applications en cours de dveloppement, leur tat de
dveloppement et leurs plans de sorties. Cependant, des processus bien dfinis et une gestion
automatise liminent ces feuilles de calcul et ces runions et permettent des sorties de versions
plus rationnelles et surtout plus prvisibles. En appliquant les pratiques Lean et Agile, les versions
publies sont plus petites et plus frquentes, et elles permettent d'accorder une plus grande
attention la qualit.

IV-C-3-c. Intgration continue

L'intgration continue (dcrite dans le chapitre 2) ajoute une valeur considrable DevOps en
permettant aux grandes quipes de dveloppeurs, travaillant sur des composants multitechnologies
sur des sites distribus, de dlivrer du logiciel avec agilit. Elle permet de s'assurer que le travail
de chaque quipe est intgr en continu celui des autres quipes de dveloppement, puis valid.
Par consquent, l'intgration continue rduit les risques et identifie les problmes en amont dans le
cycle de vie du dveloppement logiciel.

IV-C-3-d. Dploiement continu

L'intgration continue dbouche naturellement sur le dploiement automatis : un processus

d'automatisation du dploiement des logiciels dans les environnements de test, de test systme, de
prproduction et de production. Bien que certaines organisations s'arrtent la production, celles
qui adoptent DevOps utilisent gnralement le mme processus dans tous les environnements pour
amliorer l'efficacit et rduire les risques lis des processus incohrents.

Dans les environnements de test, l'automatisation de la configuration, l'actualisation des donnes,

le dploiement du logiciel dans l'environnement de test, puis l'excution de tests automatiss
acclrent les cycles de retour des rsultats des tests vers l'quipe du dveloppement.

Gnralement, l'adoption du dploiement automatis est la partie la plus importante de l'adoption

de DevOps. Pour beaucoup d'utilisateurs de DevOps, DevOps est limit l'automatisation du
dploiement. Du coup, la plupart des outils dsigns comme outils DevOps se limitent uniquement
ce processus.

Cependant, comme vous pouvez le noter dans ce manuel, DevOps couvre un champ beaucoup plus
large. L'automatisation du dploiement est un composant important de DevOps, mais ce n'est pas
le seul composant.

Selon les besoins mtier et les dfis de votre entreprise, vous pouvez commencer l'adoption de
DevOps en utilisant n'importe lequel des processus ou chemins d'adoption dcrits dans le chapitre
2.

IV-C-3-e. Tests continus

Les tests continus ont t prsents dans le chapitre 2. D'un point de vue du processus, vous
devez adopter des processus dans trois domaines pour mettre en place les tests continus :

test de provisionnement et de configuration de l'environnement ;

gestion des donnes de tests ;
test d'intgration, fonctionnels, de performance et de scurit.
Dans une organisation, les quipes d'assurance-qualit doivent dterminer les processus adopter
pour chacun de ces domaines. Les processus qu'elles adoptent varient en fonction du projet, des
besoins particuliers en tests et des exigences sur les contrats de niveaux de service (SLAs). Par
exemple, il peut tre ncessaire d'excuter un plus grand nombre de tests de scurit sur les
applications destines au client que sur les applications internes. Les tests de provisionnement
d'environnements et de gestion des donnes sont les dfis les plus importants des projets qui
utilisent les mthodologies Agile et l'intgration continue, par rapport aux projets qui suivent une
mthodologie Waterfall et excutent des tests uniquement une fois tous les deux ou trois mois. De
mme, les exigences de tests fonctionnels et de performances pour les applications complexes
constitues de composants ayant des cycles de dploiement divers diffrent de celles des
applications Web monolithiques simples.

IV-C-3-f. Surveillance et retours continus

Les retours des clients revtent diffrentes formes : tickets ouverts par le client, demandes
formelles de modification, rclamations informelles ou valuations sur les magasins d'applications
(app stores). Du fait du succs des rseaux sociaux et des magasins d'applications (voir le chapitre
5), les entreprises ont besoin de processus bien dfinis pour traiter les retours d'une multitude de
sources diffrentes et pour les intgrer dans les plans de dploiement des logiciels. Ces processus
doivent galement tre suffisamment agiles pour s'adapter au march et l'volution des
rglementations.

Les retours peuvent aussi provenir de la surveillance des donnes. Ces donnes sont issues des
serveurs sur lesquels s'excute l'application (serveurs de dveloppement, de QA ou de production)
ou bien d'outils de mesure intgrs l'application, qui capturent les actions de l'utilisateur.

Une surcharge de donnes peut se produire. Par consquent, les entreprises doivent utiliser des
processus de capture et d'utilisation des donnes qui amliorent les performances des applications
et les environnements o elles sont excutes.

Mesure de l'adoption des processus

Vous pouvez mesurer le succs de l'adoption des processus en mesurant si un ensemble
de mtriques d'efficacit et de qualit s'amliorent au fil du temps. Ces types de
mtriques impliquent deux conditions :

vous devez identifier les mtriques d'efficacit et de qualit appropries. Ces

mtriques doivent prsenter un rel intrt pour l'entreprise ;
vous devez dfinir le niveau de base par rapport auquel vous pourrez constater
les amliorations.

Vous pouvez utiliser n'importe lequel des nombreux modles dj existants pour mesurer
la maturit des processus. Pour les processus DevOps, de nouveaux modles, tels que
IBM DevOps Maturity Model, peuvent valuer la maturit spcifique de vos organisations
DevOps. Plus d'informations sur le modle de maturit IBM sont disponibles sur le site
ibm.biz/adoptingdevops.

IV-D. Les technologies dans DevOps

Les technologies permettent aux individus de se concentrer sur le travail de cration forte valeur
ajoute tout en dlguant les tches routinires l'automatisation. Elles donnent galement la
possibilit aux quipes d'ajuster et d'optimiser le temps et leurs capacits.

Si une organisation cre et gre plusieurs applications, tout ce qu'elle fait doit pouvoir tre rpt
de manire fiable pour garantir la qualit dans chacune des applications. Il ne faut pas tout
recommencer depuis le dbut chaque nouvelle sortie de version ou correction d'erreur des
applications. Elle doit rutiliser les actifs, le code et les pratiques pour rduire les cots et tre
efficace.
La standardisation de l'automatisation rend galement les individus plus efficaces (voir Les
individus dans DevOps dans les pages prcdentes de ce chapitre). Les organisations peuvent
tre confrontes au remplacement des employs, des sous-traitants ou des fournisseurs de
ressources ; les personnes peuvent changer de projet. Par contre, un ensemble d'outils communs
permettra aux utilisateurs de travailler sur n'importe quel projet, et de nouveaux membres
dquipes n'auront apprendre matriser qu'un seul ensemble d'outils un processus efficace,
conomique, rutilisable et volutif.

IV-D-1. Infrastructure programmable

L'infrastructure programmable est une fonctionnalit importante de DevOps qui permet aux
organisations de grer l'chelle et la rapidit auxquelles les environnements doivent tre
provisionns et configurs pour permettre le dploiement en continu. Autour de la notion
d'infrastructure programmable gravite la notion des environnements SDE (Software-Defined
Environments).

Alors que l'infrastructure programmable est lie la capture des dfinitions et des configurations
de nuds en tant que code, les environnements SDE utilisent des technologies qui dfinissent des
systmes entiers constitus de plusieurs nuds pas simplement leurs configurations, mais
galement leurs topologies, rles, relations, rgles de charges de travail et comportement.

Trois types d'outils d'automatisation sont disponibles pour grer :

outils d'applications ou de middleware :ces outils peuvent gnralement

grer comme du code, les serveurs d'applications et les applications qui s'y
excutent. Ces outils spcialiss disposent galement de bibliothques de
tches d'automatisation types pour les technologies qu'ils prennent en
charge. Ils ne peuvent pas excuter les tches de bas niveau, telles que
configurer un systme d'exploitation, mais ils peuvent automatiser
compltement les tches de niveau serveur et applicatif ;
outils d'environnement de dploiement :ces outils appartiennent une
nouvelle catgorie d'outils qui peuvent dployer la fois des configurations
d'infrastructure et du code applicatif ;
outils gnriques : ces outils ne sont pas spcialiss pour une technologie
spcifique et peuvent tre scripts pour excuter divers types de tches, de
la configuration d'un systme d'exploitation sur un nud virtuel ou physique
la configuration des ports de pare-feu. Ils ncessitent une plus grande
quantit de travail initial que les outils d'applications ou middleware, mais ils
peuvent traiter un plus grand nombre de tches.

En utilisant un outil de gestion et de dploiement d'environnement tel qu'IBM UrbanCode Deploy

with Patterns, les organisations peuvent concevoir, dployer et rutiliser rapidement des
environnements et acclrer le pipeline de distribution.

IV-D-2. Pipeline de distribution

Un pipeline de distribution est constitu des tapes par lesquelles passe une application, du
dveloppement la production. L'illustration 3-1 montre un ensemble d'tapes types. Ces tapes
peuvent varier en fonction de l'organisation, mais galement de l'application, selon les besoins, le
processus de distribution du logiciel et la maturit de l'entreprise. Le niveau d'automatisation peut
galement varier : certaines organisations automatisent compltement leurs pipelines de
distribution. D'autres soumettent leur logiciel des vrifications et tapes manuelles du fait
d'exigences rglementaires ou propres la socit. Il n'est pas ncessaire de traiter toutes les
tapes immdiatement. Commencez par traiter les parties critiques de l'organisation pas tout
d'un coup puis incluez progressivement chacune des tapes.
Illustration 3-1 ; tapes d'un pipeline de distribution DevOps type.

Un pipeline de distribution type comporte les tapes dcrites dans les sections suivantes.

IV-D-2-a. Environnement de dveloppement

Le dveloppement d'une application se droule dans un environnement de dveloppement qui

fournit des outils permettant aux dveloppeurs d'crire et de tester le code. Mis part les outils
IDE (Integrated Development Environment) que les dveloppeurs utilisent pour crire le code,
cette tape inclut des outils qui permettent le dveloppement collaboratif, tels que des outils de
gestion de configuration logicielle, de gestion des lments de travail, de collaboration, de test
unitaires et de planification de projet. Les outils dans cette tape sont gnralement des outils
multiplateformes et multitechnologies bass sur le type de dveloppement raliser.

IV-D-2-b. tape de gnration

L'tape de gnration est l'tape au cours de laquelle le code est compil pour crer et tester les
fichiers binaires dployer. Plusieurs outils de gnration peuvent tre utiliss ce stade en
fonction de besoins multiplateformes et multitechnologies. Les quipes de dveloppement utilisent
gnralement des serveurs de gnration pour faciliter un plus grand nombre de gnrations
ncessaires en permanence dans le cadre d'une intgration continue.

IV-D-2-c. Rfrentiel de package

Un rfrentiel de package(appel galement rfrentiel d'actifs ou rfrentiel d'artefacts) est un

mcanisme de stockage commun pour les fichiers binaires crs pendant la gnration. Ces
rfrentiels doivent galement contenir les actifs associs aux fichiers binaires pour faciliter leur
dploiement, tels que les fichiers de configuration, les fichiers d'infrastructure programmable et les
scripts de dploiement.

IV-D-2-d. Environnement de test

Un environnement de test est l'emplacement dans lequel les quipes d'assurance qualit, les
quipes d'acceptation utilisateur et celles de dveloppement/test excutent les tests. Divers types
d'outils sont utiliss au cours de cette tape, en fonction des besoins de qualit. Voici quelques
exemples :

Test de gestion de l'environnement : ces outils facilitent le

provisionnement et la configuration des environnements de test. Ils
incluent les technologies d'infrastructure programmable et (si
l'environnement est dans le cloud) les outils de provisionnement et de
gestion du cloud ;
Gestion de la donne de test : pour une organisation qui veut mettre
en place les tests continus, la gestion des donnes de test est une
fonction essentielle. Le nombre de tests pouvant tre excuts et leur
 frquence d'excution sont limits par le volume de donnes
disponibles pour les tests et la vitesse laquelle les donnes peuvent
tre actualises ;
Test d'intgration, fonctionnel, de performance et de
scurit : des outils automatiss sont disponibles pour chacun de ces
types de tests. Ces outils doivent tre intgrs un outil ou un
rfrentiel de gestion des actifs de test commun o tous les scnarios
de test, scripts de test et rsultats associs peuvent tre stocks et la
traabilit effectue vers le code, les exigences et les dfauts ;
Virtualisation des services : les applications actuelles ne sont pas
des applications monolithiques simples. Il s'agit de systmes complexes
qui dpendent d'autres applications, serveurs d'applications, bases de
donnes et mme d'applications et de sources de donnes tierces.
Malheureusement, lors des tests, ces composants peuvent ne pas tre
disponibles ou peuvent tre coteux. Les solutions de virtualisation de
services simulent le comportement la fonctionnalit et les
performances des composants d'une application pour permettre les
tests de bout en bout de l'application dans son ensemble. Ces outils
crent des bouchons de simulation (composants virtuels) des
applications et services ncessaires l'excution des tests. Le
comportement et les performances de l'application peuvent tre tests
lorsqu'elle interagit avec ces parties de code du bouchon de simulation.
IBM Rational Test Virtualization Server fournit ces fonctions de
virtualisation des tests.

IV-D-2-e. Environnements de promotions et de production

Les applications sont dployes dans les environnements de promotions et de production. Les
outils utiliss au cours de ces tapes incluent les outils de gestion et de provisionnement de
l'environnement. Les outils pour l'infrastructure programmable jouent galement un rle essentiel
dans ces tapes du fait de l'tendue des environnements au cours de ces tapes. Avec l'avnement
des technologies de virtualisation et de cloud, les environnements de promotions et de production
peuvent tre constitus aujourd'hui de centaines, voire de milliers de serveurs. Les outils de
surveillance permettent aux organisations de surveiller les applications dployes dans
l'environnement de production.

IV-D-3. Automatisation du dploiement et gestion des versions

La gestion de l'automatisation du dploiement des applications d'un environnement de promotion

l'autre implique d'utiliser des outils spcialiss dont certains sont abords dans les sections
suivantes.

IV-D-3-a. Automatisation du dploiement

Les outils d'automatisation du dploiement sont les principaux outils dans l'univers DevOps. Ces
outils excutent l'orchestration des dploiements et identifient la version dploye et le nud
concern au cours de n'importe quelle tape du pipeline de la gnration et du dploiement. Ils
peuvent galement grer les configurations d'environnement de toutes les tapes au cours
desquelles les composants de l'application doivent tre dploys.

Mesure de l'adoption des technologies

Mesurer le retour sur investissement des outils et des technologies est plutt simple.
Gnralement, vous pouvez mesurer les amliorations cres par l'automatisation.
En outre, les outils automatiss permettent d'amliorer la scalabilit et la fiabilit des
tches de dploiement ce qui n'est pas toujours possible avec des outils manuels.
En fin de compte, l'utilisation d'un ensemble d'outils automatiss intgrs facilite la
collaboration et la traabilit, et amliore la qualit.
Les outils d'automatisation du dploiement grent les composants logiciels dploys, les
composants middleware et les configurations middleware devant tre mis jour, les composants
de base de donnes qui doivent tre modifis et les modifications de configuration des
environnements sur lesquels ces composants doivent tre dploys. Ces outils permettent de
dfinir et automatiser galement les processus pour excuter les modifications de ces composants
et configurations. IBM UrbanCode Deploy est un outil de dploiement de ce type.

IV-D-3-b. Gestion des versions d'applications

L'orchestration des plans de versions et des dploiements associs ncessite une coordination
entre les quipes mtier, de dveloppement, d'assurance qualit et enfin celles des oprations. Les
outils de gestion et planification de versions permettent aux organisations de planifier et raliser
les sorties de versions, fournissent un portail de collaboration unique pour toutes les parties
impliques dans une version de l'application et permettent la traabilit d'une version de
l'application et de ses composants dans tous les environnements du pipeline de gnration et de
dploiement d'une application. IBM UrbanCode Release offre ces fonctions de gestion de versions
applicatives.

V. Chapitre 4 : Comment le cloud acclre DevOpS

Dans ce chapitre :

Utilisation du cloud comme facilitateur de DevOps ;

Description des dploiements de la pile matrielle/logicielle complte ;
Les diffrents modles de service cloud ;
Dcouverte du cloud hybride.

DevOps et le cloud agissent mutuellement comme deux catalyseurs et facilitateurs. Lorsqu'une

entreprise adopte le cloud, la proposition de valeur d'exploitation du cloud pour hberger une
activit DevOps devient vidente. La flexibilit, la rsilience, l'agilit et les services qu'apporte une
plateforme cloud permettent de rationaliser un pipeline de dploiements d'applications hberg sur
le cloud. Les environnements, du dveloppement aux tests jusqu' la production, peuvent tre
provisionns et configurs selon le besoin et lorsqu'il y en a besoin. Ce processus rduit les goulots
d'tranglement relatifs aux environnements dans le processus de dploiement. Les organisations
renforcent galement l'exploitation des plateformes cloud pour rduire les cots des
environnements de dveloppement et de tests ou pour fournir une exprience de dveloppement
rationalise moderne pour leurs utilisateurs. Ces lments constituent des scnarios mtier
extrmement incitatifs pour adopter le cloud avec et pour DevOps.

Ce chapitre explore les diffrents modles de cloud pour DevOps et examine la proposition de
valeur de DevOps comme charge de travail sur le cloud.

V-A. Utilisation du cloud comme facilitateur pour DevOps

DevOps a pour principal objectif de rduire les goulots d'tranglement dans le pipeline de
distribution pour le rendre plus efficace. L'un des principaux goulots d'tranglement auxquels font
face les entreprises concerne la disponibilit et la configuration des environnements. Il n'est pas
rare de voir les utilisateurs, notamment les dveloppeurs et les testeurs, demander un
environnement par le biais d'un systme de gestion de tickets traditionnels, la satisfaction de ces
demandes pouvant prendre des jours, voire des mois.

DevOps offre l'avantage, entre autres, de pouvoir dvelopper et tester dans un environnement
similaire la production. Au goulot d'tranglement de la disponibilit de l'environnement s'ajoute le
risque d'avoir un environnement disponible diffrent de celui de production. Cette discordance peut
se limiter de simples diffrences dans la configuration de l'environnement au niveau du
systme d'exploitation ou du middleware, ou bien elle peut tre beaucoup plus grave avec la
prsence d'un type de systme d'exploitation ou de middleware dans les environnements de
dveloppement, totalement diffrent de celui de l'environnement de production.
L'absence de disponibilit des environnements se traduit par des dlais d'attente potentiellement
longs pour les utilisateurs. La discordance entre les environnements de dveloppement et de
production peut poser des problmes de qualit significatifs, car les dveloppeurs ne peuvent pas
vrifier le comportement de l'application telle qu'elle sera dploye dans l'environnement de
production, ou pire, ne peuvent pas valider que le processus de dploiement valid sur les
environnements de tests fonctionnera lorsqu'il faudra dployer dans l'environnement de
production.

Le cloud rsout ces problmes de la manire suivante :

la rapidit du provisionnement d'environnement sur les plateformes cloud peut

fournir aux utilisateurs un accs d'usage en libre-service avec une disponibilit
d'environnement et un accs la demande ;

la possibilit de provisionner et de dcomissionner dynamiquement ces

environnements en fonction des besoins, amliore la gestion des environnements
et diminue les cots en rduisant la ncessit d'avoir des environnements de
tests statiques permanents ;
la possibilit d'exploiter des technologies qui s'appuient sur des modles et
qui donnent la possibilit aux organisations de dfinir et versionner les
environnements comme du logiciel permet de fournir des environnements qui
rpondent exactement aux besoins des utilisateurs et qui correspondent
surtout des environnements de type production ;

du point de vue de l'automatisation, la disponibilit des technologies

d'automatisation du dploiement des applications, telles que IBM UrbanCode
Deploy, permet avec un seul outil de provisionner l'environnement cloud et de
dployer les versions appropries vers ces environnements en fonction des
besoins et quand cela est ncessaire. Ces technologies peuvent galement
configurer rapidement l'environnement et l'application pour rpondre aux besoins
des utilisateurs ;
la disponibilit des technologies de virtualisation de services, telles qu'IBM
Rational Test Virtualization Server, fonctionnant conjointement avec les
environnements cloud, permet de simuler les services ncessaires aux tests sans
avoir provisionner des instances relles de ces services.

L'illustration 4-1 montre comment les environnements cloud fonctionnent conjointement avec les
technologies d'automatisation du dploiement et de virtualisation de services pour fournir des
environnements de dveloppement/test de bout en bout.
 Illustration 4-1 : environnement
de dveloppement/test de bout en bout dans lecloud.

Le cloud sans DevOps c'est perdre tous les avantages qu'offre le cloud. L'adoption de DevOps avec
des environnements hbergs dans le cloud permet d'offrir aux organisations qui dveloppent et
dploient des applications logicielles l'ensemble des fonctionnalits et des bnfices qu'elles
peuvent tirer du cloud.

V-B. Dploiement de pile matrielle/logicielle complte

Le dploiement d'une application cloud consiste dployer l'application et configurer

l'environnement cloud o elle s'excute. Ces deux tches peuvent tre excutes sparment,
mais lorsqu'elles sont combines, cette opration s'appelle le dploiement de pile complte. Ces
deux approches sont traites plus en dtail dans cette section.

La premire approche consiste sparer le provisionnement d'environnement cloud du

dploiement de l'application. Dans ce cas, il n'existe pas un point unique d'orchestration des
environnements cloud et des applications qui y sont dployes. L'outil d'automatisation du
dploiement d'application considre les environnements cloud comme des environnements
statiques. Ce scnario n'optimise pas les avantages du dploiement dans le cloud.

La seconde approche consiste utiliser l'outil d'automatisation du dploiement applicatif comme

outil d'orchestration unique pour le provisionnement d'environnement cloud et pour le dploiement
des applications dans ces environnements provisionns. Cela peut se faire en crant des
modles qui dfinissent l'environnement cloud et sa topologie et qui associent les composants
d'application et la configuration aux nuds dfinis dans l'environnement cloud.

Plusieurs technologies de modles, telles que les modles IBM Virtual System Patterns et
OpenStack Hot, peuvent tre utilises pour dfinir des modles d'environnements Clould. Les outils
d'automatisation du dploiement, tels qu'IBM UrbanCode Deploy with Patterns, peuvent fournir un
provisionnement de pile complte en utilisant ces modles. Cela inclut le provisionnement de
l'environnement cloud dfini dans le modle et le dploiement de l'application dans ce nouvel
environnement. Une fois l'environnement provisionn, des modifications d'application, de
configuration et de contenu peuvent tre dployes en continu dans l'environnement cloud sous
forme de mises jour.

Les organisations peuvent galement dcider de procder un dploiement de pile complte

lorsque les environnements et les applications associes sont toujours provisionns ensemble
comme un seul et mme actif dployer. Dans ce cas aucune mise jour n'est apporte
l'environnement existant.
 V-C. Choix d'un modle de service cloud pour DevOps

Lors de l'adoption du cloud, vous devez d'abord dterminer l'ensemble des responsabilits que
vous souhaitez voir prises en charge par la plateforme cloud et celles que vous souhaitez prendre
en charge vous-mme. Il existe deux principaux modles de service pour le cloud : Infrastructure
as a Service (IaaS) et Platform as a Service (PaaS).

V-C-1. Iaas

Lors de l'adoption du cloud dans un modle IassS, la plateforme cloud gre l'infrastructure sous-
jacente et fournit les fonctionnalits et les services qui permettent de grer toute l'infrastructure
virtualise. L'installation, les correctifs et la gestion du systme d'exploitation, le middleware, les
donnes et l'application restent dans le domaine de responsabilit de l'utilisateur.

Dans le contexte de l'adoption de DevOps dans un contexte de travail dans le cloud, le choix du
modle de service cloud utiliser dtermine la manire dont DevOps sera adopt. Pour le modle
de service IaaS, l'organisation d'utilisateurs est charge de grer l'ensemble du pipeline de
distribution. Tous les outils et intgrations du pipeline de dploiement deviennent la responsabilit
des quipes utilisateurs, y compris l'acquisition des outils adquats et leur intgration pour dfinir
le pipeline de distribution. En outre, ils doivent s'assurer que la collaboration entre les quipes de
dveloppement et celles des oprations respecte bien l'approche DevOps. Ce n'est pas parce
qu'une plateforme cloud est utilise comme service cloud qu'il n'est plus ncessaire de supprimer
les silos de responsabilits entre les dveloppeurs qui fournissent le code et les quipes des
oprations qui fournissent l'infrastructure.

Bien que le cloud apporte une valeur considrable en fournissant une infrastructure IaaS aux
quipes de livraison et dploiement des applications, cela n'empche pas que ces quipes ont
toujours besoin de toutes les fonctionnalits de DevOps pour pouvoir fournir la valeur que DevOps
peut leur apporter.

Sparation des responsabilits

L'un des principaux problmes lis l'exploitation de DevOps sur le cloud IaaS rside dans la
dfinition de la sparation des responsabilits entre la plateforme cloud et l'outil de
dploiement d'application. Quel outil pour quelle responsabilit ? Une approche simple en la
matire consiste se placer du point de vue des actifs de la pile cloud selon qu'ils aient besoin
d'voluer rapidement ou lentement. Le tableau ci-dessous montre les diffrentes couches de la
pile matrielle/logicielle, des couches systme d'exploitation, stockage et rseau jusqu'
l'application.
 Les couches de configuration d'application, de donnes et de middleware voluent rapidement
par nature. Elles voluent souvent, car l'application, ses donnes et son utilisation se
renouvellent sans arrt. Le changement peut tre trs rapide pour une application qui est
toujours en cours de dveloppement. Les couches infrieures dans ce cas incluent le
middleware (serveur d'applications, base de donnes, etc.), le systme d'exploitation et le
stockage, et elles ne changent pas si frquemment. Comme la mise jour et le
rapprovisionnement de toutes les couches pour une simple modification qui affecte
uniquement l'application, son contenu et la configuration ne seraient pas une mthode efficace,
il est logique de sparer les responsabilits de ces couches volutions lente et rapide entre
un outil de dploiement d'application et un outil de gestion cloud. Les couches volution
rapide sont gres et automatises par l'outil de dploiement d'application et les couches
volution lente le sont par le logiciel de gestion cloud fourni par la plateforme cloud.

V-C-2. PaaS

En adoptant un modle PaaS, vous tes responsables uniquement de l'application et des donnes.
Toutes les autres fonctionnalits sont fournies par la plateforme PaaS. De ce fait, l'exprience
utilisateur s'en trouve nettement amliore pour les quipes de dploiement d'applications. Les
outils de dveloppement et de test d'application sont dsormais disponibles comme services sur la
plateforme accessible aux utilisateurs. L'organisation distributrice d'applications n'est plus
responsable de la gestion du pipeline de distribution. En fait, elle est incorpore dans PaaS et
permet aux utilisateurs de se concentrer exclusivement sur la distribution rapide des applications.
Tous les outils de dveloppement et de test et le provisionnement d'infrastructure ne sont plus des
services incombant aux utilisateurs, ce qui leur permet de se concentrer sur les tches principales
de dploiement des applications.

IBM Bluemix est un PaaS. IBM et ses partenaires grent la plateforme et les services qui y sont
fournis. La plateforme inclut IBM DevOps Services un ensemble de services fournissant toutes
les fonctionnalits permettant aux quipes d'adopter DevOps, et plus particulirement un pipeline
de dploiement d'applications comme groupe de services. Les quipes de dploiement
d'applications peuvent utiliser les services sans se proccuper de la manire dont ceux-ci sont
hbergs et fournis. Les services DevOps dans le cloud incluent ce qui suit :

environnement de dveloppement intgr (Integrated Development

Environment) Web comme service ;
fabrication de l'application comme service ;
planification et gestion des tches comme service ;
analyse de la scurit comme service ;
dploiement comme service ;
surveillance et analyse comme service.

La plateforme fournit galement des environnements d'excution volutifs pour les applications
excutes dans diffrents environnements dans le cycle de vie de distribution du
dveloppement, jusqu'aux tests, qualification et la production.

V-D. Description d'un cloud hybride

Le terme cloud hybride est trs employ dans le domaine du cloud. Il est probablement un peu
galvaud pour dcrire des scnarios cloud o plusieurs technologies cloud coexistent ou dans
lesquels une infrastructure cloud et une infrastructure physique coexistent.

Une mthode simple pour dfinir un cloud hybride consiste examiner cette multitude de scnarios
de cloud.

Infrastructure cloud et infrastructure physique : scnario de cloud hybride

trs courant. Il s'agit du scnario standard, moins que l'entreprise soit ne dans
le cloud. Toutes les organisations ont des charges de travail et des applications
 qui s'excutent dans leur infrastructure physique existante. Dans la plupart des
cas, certaines de ces applications continuent de fonctionner sur l'infrastructure
physique. Les applications mainframe et les systmes d'enregistrements forts
volumes de donnes qui ne peuvent tre migrs vers le cloud du fait des
contraintes technologiques et de cot sont des exemples types. Mme si une
organisation migre toutes ses charges de travail vers le cloud, la migration ne
peut pas tre excute du jour au lendemain, et l'infrastructure physique
coexistera avec l'infrastructure cloud pendant une priode plus ou moins longue.
cloud sur site et cloud hors site : dans ce scnario, une entreprise peut
adopter un cloud hors site (public ou priv virtuel) pour certaines applications et
charges de travail, et un cloud sur site (priv) pour les autres. Il peut s'agir, par
exemple, d'une organisation qui exploiterait un cloud hors site conomique pour
grer ses environnements de dveloppement, et un cloud sur site autogr dans
son propre centre de donnes pour toutes les charges de travail de production.
IaaS et PaaS : ce scnario inclut les clients ayant adopt un modle de service
Cloud PaaS pour certaines charges de travail nouveaux systmes innovants
d'applications de type engagement, par exemple et IaaS pour un systme plus
traditionnel de charges de travail d'enregistrement.

Pour l'adoption de DevOps, l'existence d'un cloud hybride prsente de nouveaux dfis, car dans ce
cas, il existe des pipelines de distribution d'applications qui couvrent des environnements de cloud
hybride et physiques complexes. Exemples d'environnements cloud hybride :

une organisation peut dcider d'utiliser un cloud public pour le dveloppement,

les tests et les autres environnements de non-production, et un cloud sur site, ou
mme une infrastructure physique, pour la production ;
une organisation peut disposer d'un systme d'applications d'engagement
dploy dans un environnement cloud, alors que les systmes d'applications
d'enregistrements qui fournissent les services back-end pour les principales
applications mtier peuvent toujours rsider dans l'infrastructure physique, par
exemple un mainframe ;
les organisations peuvent tirer parti d'un PaasS public pour l'exprimentation
avec les applications innovantes et vouloir les placer dans un cloud priv
lorsqu'une exprimentation aboutit ;
les organisations peuvent vouloir porter les charges de travail d'application sur
plusieurs plateformes cloud pour ne pas tre dpendantes d'un seul fournisseur
ou pour permettre de dployer les charges de travail critiques sur des clouds de
plusieurs fournisseurs.

Le dploiement d'applications dans ces divers environnements cloud et physiques constitue la

principale ncessit de l'adoption DevOps dans un cloud hybride. Les applications, telles qu'IBM
UrbanCode Deploy with Patterns, utilisent des modles pour associer les applications et les
configurations plusieurs environnements, physiques ou cloud, ce qui permet d'utiliser le
dploiement automatis dans les environnements cloud hybrides.

VI. Chapitre 5 : Utilisation de DevOps pour relever les nouveaux dfis

Dans ce chapitre

Activation des applications mobiles ;

Traitement des processus ALM ;
Agilit grande chelle ;
Gestion des applications multitiers ;
Regard sur DevOps dans l'entreprise ;
Utilisation des chanes logistiques ;
Navigation sur l'Internet des objets.
DevOps est apparu dans les entreprises nes sur le Web(entreprises qui ont cr l'origine leur
activit sur Internet), telles qu'Etsy, Flickr et NetFlix. Ces socits, tout en relevant des dfis
technologiques complexes une trs grande chelle, utilisaient une architecture plutt simple
contrairement aux entreprises qui se sont dveloppes autour de systmes existants et par le biais
d'acquisition et de fusions, avec des systmes faisant appel diverses technologies qui devaient
fonctionner ensemble. Ces dfis sont encore plus considrables du fait des exigences qu'imposent
sur les entreprises actuelles les nouvelles technologies comme les mobiles et les modles de
livraisons d'applications telles que les chanes logistiques logicielles.

Ce chapitre explore certains de ces dfis auxquels les entreprises font face et que DevOps peut
permettre de surmonter.

VI-A. Applications mobiles

Dans une entreprise, en rgle gnrale, les applications mobiles ne sont pas des applications
autonomes. Leur logique applicative sur l'appareil mobile est trs limite, et ces applications font
surtout office d'interfaces avec les applications d'entreprise dj utilises dans l'entreprise. Ces
applications d'entreprise back-end peuvent tre aussi bien des systmes de traitement de
transactions que des portails employs ou encore des systmes d'acquisition de clients. Le
dveloppement et la fourniture d'applications mobiles sont complexes et ncessitent de fournir un
ensemble de services dpendants de manire coordonne, avec toute la fiabilit et l'efficacit
ncessaires.

Pour les applications mobiles d'entreprise, les cycles de publication et les publications de nouvelles
fonctions doivent tre coordonns avec les applications et services qui interagissent avec elles. Par
consquent, l'adoption de DevOps doit englober imprativement les quipes ddies aux
applications mobiles, ainsi que les autres quipes de dveloppement de logiciels dans l'entreprise.

DevOps et les magasins d'applications

Le dploiement des applications mobiles sur les magasins d'applications est un aspect propre ces
applications. La plupart des applications mobiles ne peuvent pas tre dployes directement sur
les appareils mobiles ; elles doivent passer par un magasin d'applications gr par le fournisseur.
Apple a introduit cette formule de distribution avec son App Store (et verrouill ses appareils pour
empcher l'installation directe des applications par les dveloppeurs et les fournisseurs
d'applications). Les fabricants d'appareils, tels que Research In Motion, Google et Microsoft, qui
autorisaient auparavant l'installation directe des applications, ont repris le modle Apple. Cette
situation introduit une tape supplmentaire asynchrone dans le processus de dploiement. Les
dveloppeurs ne peuvent plus dployer la demande les mises jour d'une application. Mme
pour les correctifs critiques, les nouvelles versions d'application doivent passer par les processus
de soumission et de vrification d'un magasin d'applications. La livraison continue se transforme
en soumission et en attente. Le dploiement continu pour le dveloppement et les tests restent
disponibles, mais avec un environnement constitu de simulateurs des appareils sur lesquels les
applications seront dployes ou des bancs d'appareils physiques.

Quatre-vingts pour cent des donnes d'entreprise proviennent du mainframe, et soixante-dix pour
cent de toutes les transactions touchent un mainframe. L'ouverture d'un chemin d'accs mobile
vers ces fonctions de mainframe peut changer la manire de mener l'entreprise et d'approcher les
clients, mais l'objectif peut s'avrer compliqu. Vous pouvez tre confront un manque de
comptences, des silos organisationnels ou une htrognit de plateformes qui allongent les
cycles de livraison, gnrent des retards inutiles et consomment normment de ressources. Pour
fournir un mobile ces applications, les entreprises utilisent DevOps, une approche de distribution
de logiciel qui repose sur la rapidit et l'efficacit sans sacrifier la stabilit et la qualit.

Aucun concept ou principe DevOps spcifique ne s'applique uniquement aux applications mobiles.
Cependant, les applications mobiles ncessitent d'autant plus de recourir DevOps que leurs cycles
de dveloppement sont courts et leur volution rapide inhrente.

VI-B. Processus ALM

ALM (Gestion du cycle de vie des applications) est l'ensemble des processus dploys pour grer le
cycle de vie d'une application, de l'ide (besoin) la ralisation de l'application qui est dploye et
la fin en maintenance. Ainsi, en considrant DevOps comme une fonctionnalit mtier de bout en
bout, ALM devient le concept fondamental qui sous-tend le processus DevOps. DevOps largit le
champ ALM pour inclure les responsables mtier, les clients et les oprations dans le processus.

Le chemin d'adoption Dveloppement/Test DevOps (voir le chapitre 2 pour plus d'informations) est
plus en conformit avec les fonctionnalits ALM traditionnelles de gestion des besoins, des
changements, du contrle de version, de la traabilit et de gestion des tests. Cependant, les
autres fonctionnalits ALM, telles que le suivi et la planification, interviennent dans le chemin
d'adoption Pilotage. Les tableaux de bord et les rapports sont quant eux inclus dans le chemin
d'adoption Exploitation.

VI-C. Extension d'Agile

Le dveloppement selon les principes Lean et Agile sont les points cls de l'approche DevOps
l'un des rsultats tant la rduction du gaspillage avec des quipes plus performantes. L'efficacit
et la rptition des meilleures pratiques acclrent les cycles de dveloppement en permettant aux
quipes d'tre plus innovantes et plus ractives et donc d'augmenter la valeur client. L'extension
des principes d'efficacit et d'agilit (Lean et Agile) au-del de l'quipe de dveloppement une
quipe d'quipes et l'ensemble du cycle de vie de livraison des produits et des applications est au
cur de l'approche DevOps.

La plupart des quipes ont dj adopt l'agilit et veulent tendre leurs processus actuels dans leur
adoption DevOps. En rgle gnrale, de nombreux modles courants sont disponibles cet effet.
Ces modles comprennent Scaled Agile Framework (SAFe) et Disciplined Agile Delivery (DAD).
Certaines entreprises ont aussi tendu efficacement leur processus Scrum de trs grandes
quipes. Ces modles ont pour vocation de fournir une mthodologie pour adopter l'agilit au
niveau de l'entreprise. Cela implique de tenir compte non seulement du dveloppement du code,
mais galement de l'architecture, du financement du projet et de la gouvernance des processus et
des rles qu'impose la gestion, en appliquant prcisment les mmes principes d'efficacit et
d'agilit que ceux qui se sont avrs efficaces au niveau de l'quipe. Quelle que soit l'infrastructure
utilise pour tendre l'agilit, on utilisera les principes de base de l'agilit et on appliquera les
meilleures pratiques pour les exploiter afin d'instaurer l'efficacit et l'efficience dans l'entreprise.

VI-D. Applications multitiers

Dans une grande entreprise informatique type, il n'est pas rare de trouver des applications
multitiers qui couvrent plusieurs plateformes, ayant chacune ses propres besoins de processus de
dveloppement, outils et comptences. Gnralement, ces systmes multitiers intgrent des
applications Web, des ordinateurs et mobiles sur les systmes frontaux et back-end, telles que les
applications du commerce, les systmes d'entrept de donnes, les applications excutes sur des
mainframes et les systmes milieu de gamme. La gestion et la coordination des versions des
diffrents composants de ces systmes multiniveaux, dont la plupart peuvent se trouver sur
diffrentes plateformes, peuvent s'avrer compliques, mme pour l'entreprise informatique la
mieux organise.

Une approche raisonne consiste suivre des processus de fabrication, de configuration et de

dploiement cohrents automatiss dans toutes les tapes du dveloppement. Ainsi, vous tes
assur de gnrer tous les composants et seulement les composants dont vous avez besoin. Elle
garantit galement l'intgrit de l'application mesure que des modifications sont apportes et
pendant le cycle de test, de contrle qualit et de production du projet. IBM UrbanCode Deploy
dispose d'un modle applicatif qui permet d'automatiser le dploiement complexe des applications
multiniveaux.

La gestion d'outils distincts pour diffrentes quipes bases selon les plateformes est une ralit
dans l'environnement multifournisseur et multiplateforme actuel. Dans ce contexte, des
plateformes ouvertes, telles que IBM Jazz permettent d'intgrer des outils htrognes pour fournir
une solution unifie. Des pratiques de dploiement cohrentes permettent aux quipes d'excuter
un dploiement fiable et rutilisable sur les plateformes pour gnrer une relle valeur mtier.
 VI-E. DevOps dans l'entreprise

L'entreprise actuelle dpend de la rapidit laquelle l'informatique peut fournir le logiciel.

Gnralement, ces entreprises utilisent des systmes d'applications d'enregistrement (dveloppes
en interne ou applications du commerce) dployes sur des systmes mainframe ou milieu de
gamme. Elles sont confrontes une multitude de dfis :

obstacles rguliers ;
complexit des processus ;

exploitation inadquate des comptences ;

silos organisationnels ;
plateformes et outils qui allongent les cycles de livraisons de versions, gnrent
des retards inutiles et gaspillent les ressources.

DevOps au niveau de l'entreprise permet aux parties prenantes de la planification, du

dveloppement, des tests et des oprations de distribuer en continu le logiciel dans l'entreprise.
Actuellement, les entreprises dploient des applications qui sont rellement interplateformes, qu'il
s'agisse d'appareils mobiles ou de mainframes. L'approche DevOps du dveloppement utilise les
principes d'efficacit pour crer un pipeline de distribution efficient et efficace qui permet de
dployer, tester et distribuer les applications, car il amliore la qualit et acclre le
dveloppement tout en rduisant ses cots.

Compte tenu de la vraie nature multiplateforme des entreprises actuelles, avec l'existence
d'applications mobiles, de cloud, rparties et mainframe qui doivent tre toutes cres,
intgres, dployes et exploites, l'efficacit, la rationalisation et la collaboration qu'apporte
DevOps deviennent un vritable diffrenciateur concurrentiel essentiel.

VI-F. Chane logistique

Face au recours croissant l'externalisation et aux partenariats stratgiques pour apporter

l'entreprise les comptentes et capacits dont elle a besoin, les chanes logistiques logicielles
deviennent la norme. Une chane logistique est un systme d'organisations, de personnes, de
technologies, d'activits, d'informations et de ressources intervenant dans le processus de livraison
d'un produit ou d'un service d'un fournisseur chez un client : les divers fournisseurs dans la chane
peuvent tre internes ou externes l'entreprise.

Dans une entreprise qui a opt pour un modle de chane logistique pour la fourniture de ses
logiciels, l'adoption de DevOps peut relever du dfi, car les relations entre les fournisseurs sont
plus gres par des contrats et des accords sur les niveaux des services que par la collaboration et
la communication. Nanmoins, une telle entreprise peut toujours adopter DevOps. Les principales
quipes du projet conservent la proprit des fonctionnalits de planification et de mesure, les
autres fonctionnalits tant partages entre les autres fournisseurs. Dans le pipeline de
distribution, diffrents fournisseurs peuvent dtenir diffrents morceaux du pipeline. L'utilisation
d'un ensemble d'outils communs et d'un rfrentiel d'actifs communs est donc essentielle. Un outil
de gestion des lments de travail, par exemple, fournit des fonctions de gnration de rapports
sur tous les lments la charge de chacun des fournisseurs, et permet de transfrer la proprit
des demandes de travail aux fournisseurs. L'utilisation d'un rfrentiel d'actifs communs fournit un
mcanisme pour transmettre les actifs dans le pipeline pour permettre la livraison en continu.

VI-G. Internet des objets

L'tape suivante importante pour DevOps est son volution dans le domaine des systmes et des
appareils embarqus, o elle est gnralement appele ingnierie continue. Au dbut d'Internet, la
plupart des donnes qui y taient partages taient gnres par des individus. Aujourd'hui, un
nombre incalculable d'appareils connects Internet (capteurs et actionneurs, par exemple)
gnrent largement plus de donnes que l'tre humain. Ce rseau de priphriques interconnects
sur Internet s'appelle l'Internet des objets.
Dans cet espace, DevOps est potentiellement encore plus essentiel du fait de la coexistence du
matriel et du logiciel incorpor qui s'y excute. Les principes de DevOps sont reflts dans
l'ingnierie continue pour garantir que le logiciel embarqu dans les appareils est de trs haute
qualit avec les spcifications techniques appropries.

Le service Oprations dans l'ingnierie continue est remplac par des techniciens matriel ou
systme qui conoivent des matriels personnaliss pour les priphriques. La collaboration entre
les quipes de dveloppement et de test et les ingnieurs systme est cruciale pour dvelopper et
fournir des matriels et des logiciels d'une manire coordonne, bien que le dveloppement des
matriels et des logiciels doive suivre des cycles de livraison diffrents. Les besoins en
dveloppement et en test pour la livraison continue restent les mmes. Des simulateurs sont
utiliss pour tester le logiciel et le matriel pendant le dveloppement.

Antimodles
Dans la pratique, il existe toujours des limitations l'adoption des principes DevOps. Certaines de
ces limitations sont des fonctions des secteurs et des environnements o volue une entreprise,
telles que le respect des rglementations, les systmes matriels complexes ou les capacits de
distribution de logiciels immatures. Dans ce cas, DevOps doit tre adopt la lumire des
antimodles (modles inefficaces et contreproductifs) qui peuvent ne pas tre acceptables pour
une entreprise, en fonction de ses besoins mtier.
Water-SCRUM-fall
Forrester (www.forrester.com), une socit globale de conseil et d'tudes, utilise le terme
Water-SCRUM fall pour dcrire l'tat actuel d'adoption des mthodologies agiles de dveloppement
de logiciels. D'un point de vue DevOps, cela implique que, bien que les quipes de dveloppement
puissent avoir adopt des pratiques agiles, les quipes la priphrie peuvent toujours utiliser des
processus de type Waterfall qui ne permettent pas la livraison continue. Cette situation s'explique
par la culture d'entreprise dans plusieurs entreprises. Une entreprise qui adopte DevOps doit
intgrer des processus manuels dans des pratiques DevOps plus larges.
NoOps
Dans une organisation NoOps, le service Oprations est limin, et ses responsabilits sont
fusionnes avec celles du service Dveloppement. Netflix, un oprateur de tlvision Web, prne
cette mthode. NoOps peut bien fonctionner pour certaines entreprises, mais il convient
d'attendre afin de dterminer si ce modle organisationnel sera plbiscit.

VII. Chapitre 6 : Russir DevOps : tmoignage d'IBM

Dans ce chapitre :

description des meilleures pratiques pour les dirigeants ;

organisation de l'quipe ;
identification des objectifs DevOps ;
noter la transformation DevOps ;
apprendre partir des rsultats DevOps.

DevOps a t adopt dans l'ensemble de la socit IBM et volue rgulirement. Cette adoption
rsulte de la mise en place russie d'une dmarche DevOps initie par IBM Software Group (SWG)
Rational et qui est maintenant utilise, entre autres, dans les divisions Watson, Tivoli, Global
Business Services. Ce chapitre propose une tude de cas de l'adoption des fonctionnalits DevOps
par l'quipe produit IBM Rational Collaborative Lifecycle Management d'IBM SWG.

Cette volont d'amliorer la livraison du produit IBM Rational Collaborative Lifecycle Management a
ceci d'unique qu' elle a t mene de manire ouverte l'quipe de livraison du produit dlivre
tous ses artefacts de dveloppement et le rsultat de son travail en cours, y compris tous les
lments de travail dtaills, de manire transparente sur jazz.net. Ce site Web est accessible au
public, et les utilisateurs enregistrs peuvent consulter le travail planifi, le travail en cours et
l'historique de tout le travail de dveloppement ralis pour les produits d'IBM Rational
CollaborativeLifecycle Management.

VII-A. Le rle du management

La culture est un fil invisible dans une organisation. Elle repose sur des valeurs et des
comportements que les managers et les employs font tous voluer. Bien souvent, vous ne
comprenez pas la culture d'une organisation tant que vous n'tes pas impliqu dans un projet de
transformation significative. Il y aura toujours les sceptiques qui attendent afin de voir s'il ne s'agit
pas simplement de l'engouement du mois. Des leaders de la transformation mergeront. Il est
donc important d'tablir une approche pour comprendre ces dynamiques et identifier les rles de
chacun de manire bien identifier les vrais inhibiteurs.

Pour traiter la dynamique culturelle, les responsables d'IBM SWG ont adopt diverses approches :

Slectionner le leader appropri : le leader a pour rle de rassembler les

diffrents points de vue afin d'orienter l'quipe vers un ensemble commun
d'objectifs, d'inhibiteurs, de changements de processus et de dcisions sur les
premires tapes mettre en uvre ;
Impliquer les parties prenantes : tous ces changements doivent absolument
tre soutenus par la direction, les managers et chaque contributeur individuel des
diffrentes disciplines du dveloppement. Il faut nommer et impliquer des leaders
et experts du changement parmi les reprsentants mtier, les architectes, les
dveloppeurs, les testeurs et les oprations ;
Mesurer les amliorations et les rsultats : il est essentiel de disposer d'un
ensemble de mesures qui permettent de dgager l'efficacit et les rsultats
conomiques de ces changements. Ces objectifs et mesures doivent placer la
barre assez haut et rendre les personnes responsables en vitant le risque d'un
dsengagement ;
Crer une dynamique avec les premiers succs : la comprhension des
inefficacits existantes et la mesure des amliorations apportes par DevOps
dans chaque domaine crent une dynamique du changement ;
Communiquer et couter : en tant que leader, il est important de comprendre
la dynamique relle de l'instauration du changement dans l'quipe. Le changes
1 1 avec les individus et les interactions rgulires en face face entre les
quipes techniques, les responsables et les leaders mtier permettent d'valuer
l'adhsion de l'quipe, sa perception des inhibiteurs, et, tout aussi important,
offrent une opportunit au management de partager ses perspectives sur les
priorits et l'avancement.

Si vous tes dirigeant d'entreprise, vous devez encourager les quipes et vous rendre disponible
pour comprendre et liminer les obstacles. voluer dans une quipe soude avec des objectifs
mtier clairs est indispensable pour amener tout le monde emprunter le mme chemin.

VII-B. Constitution de l'quipe

L'quipe produit IBM SWG Rational Collaborative Lifecycle Management fait partie d'une entit plus
large qui dveloppe des outils de dveloppement de logiciels dans les domaines de la planification,
la livraison des logiciels, la gestion de la qualit des logiciels et la surveillance et l'analyse des
applications.

Cette quipe produit d'IBM SWG est une grande quipe organise l'chelle mondiale en quatre
quipes produit sur 25 sites de 10 pays. Avant d'adopter l'approche DevOps, l'activit du groupe
reposait sur une planification de sorties produit annuelles, y compris une priode de trois six mois
pour dterminer ce qu'il fallait mettre dans la sortie de la version annuelle.

VII-C. Dfinition des objectifs DevOps

L'quipe IBM SWG considra qu'elle ne ragissait pas suffisamment rapidement l'volution du
march et des besoins des clients. Elle dcida de raccourcir le cycle de sorties de versions, non
seulement dans les phases de dveloppement et de test, mais galement pour la collaboration et
les interactions avec les parties prenantes de l'entreprise et les clients. La dcision fut prise de
passer d'une planification annuelle une planification trimestrielle.
Outre la ncessit d'acclrer son dveloppement pour fournir de nouvelles fonctionnalits plus
frquemment, l'quipe devait galement s'engager plus rapidement pour prendre en charge les
modles de distribution cloud, le dveloppement et les tests d'applications mobiles et d'autres
fonctionnalits afin de prendre en compte les volutions technologiques. L'quipe dcida donc
d'adopter les principes et pratiques de DevOps pour changer le dveloppement des logiciels afin de
livrer plus rapidement et plus frquemment de la valeur pour ses clients.

Une modification d'une telle ampleur imposait un changement culturel dans l'organisation. Il fut
donc dcid de crer quatre groupes de travail constitus de membres la fois du management et
de responsables techniques. Ces groupes de travail examinrent compltement les processus de
sortie des logiciels et dcidrent de changer les mthodes de travail. Un ensemble de mesures et
plans d'action fut mis en place pour traiter les principaux points du processus de dveloppement.
Une quipe d'experts en livraison continue fut cre, et une personne fut charge de former les
quipes et de communiquer les meilleures pratiques l'ensemble de l'organisation.

L'adoption de DevOps par l'quipe IBM SWG commena en identifiant ces objectifs :

rationaliser le processus et introduire les nouvelles mthodologies ;

amliorer l'usage des outils en termes de cohrence, de mise l'chelle sur
d'autres quipes, de traabilit et de mesures ;
faire voluer la culture vers l'amlioration permanente.

VII-D. Apprendre de la transformation DevOps

Cette section explique les tapes suivies par l'quipe d'IBM SWG pour faciliter sa transformation
DevOps.

VII-D-1. tendre les pratiques Agile

Les pratiques Agile existantes furent tendues au-del du dveloppement et des tests pour inclure
les clients, les reprsentants mtier et les oprations afin d'liminer les silos et d'amliorer les
rsultats. Ce modle Agile plus large a permis aux quipes de collaborer d'apporter plus de
cohrence et de qualit aux produits logiciels dlivrs, d'apporter plus de valeur mtier
l'entreprise, tout cela en utilisant un ensemble de processus qui s'intgraient chaque tape de la
chane de dveloppement du produit.

La direction produit, la partie conception et les quipes de dveloppement furent regroupes au

sein d'une seule et mme quipe. L'quipe de dveloppement est constitue des rles traditionnels
de responsables de dveloppement et de responsables d'quipes, mais galement de la gestion des
oprations et d'architectes pour prendre en charge la stratgie de cycle de vie de bout en bout.

Des ressources ddies furent affectes l'encadrement des quipes pour couvrir les livraisons
agiles et continues l'ensemble de l'organisation. La priorit fut donne aux fonctionnalits par
rapport aux composants du produit, ce qui a permis d'liminer les silos traditionnels et d'assurer la
disponibilit et l'automatisation d'un produit livrable chaque Sprint. En outre, ces quipes
fonctionnelles furent renforces par la dsignation de responsables de dveloppement ddis. Des
runions Scrum furent organises rgulirement au niveau de l'organisation du dveloppement afin
d'identifier et d'liminer les blocages, suivre les principales mesures, utiliser des donnes de
tableau de bord dynamiques et communiquer les informations importantes.

Afin de mieux apprhender les opportunits et volutions du march et de mieux prioriser les
dveloppements, un comit produit stratgique fut cr, constitu de la direction produit, des
directeurs de dveloppement, d'architectes et de responsables mtier. Leurs responsabilits sont
les suivantes :

allocation et financement du succs de l'excution du programme ;

gestion, assistance et soutien l'excution du programme ;
tablissement d'une vision et d'une orientation long terme pour le mtier ;
 priorisation des ensembles de user stories dlivres dans les versions
annuelles pour s'aligner sur la vision long terme.

VII-D-2. Exploiter l'automatisation des tests

Pour liminer les longs cycles de test back-end traditionnels et amliorer la qualit des ditions,
une approche de test continu agile fut adopte en utilisant l'automatisation et la virtualisation. Il
fut dcid de mettre en place des itrations de quatre semaines se terminant par une dmo, et des
jalons de quatre semaines prenant fin avec une version livre utilisable par le client. Les
rtrospectives aprs chaque jalon et l'analyse des problmes techniques ont permis d'liminer les
cueils dans les itrations futures. La devise de l'quipe d'IBM SWG tait Tester en amont et
souvent. L'quipe a adopt les meilleures pratiques suivantes pour l'automatisation des tests :

automatiser les tests rptitifs et ncessitant une charge de travail

importante ;
automatiser les tests sur les parties frquemment affectes par des
dysfonctionnements ;
excuter les tests automatiss chaque gnration de l'application :
excuter tt et souvent ;
crer une automatisation des tests qui ne soit pas affecte par les volutions
de l'interface utilisateur utilisation d'une infrastructure qui spare
l'interface utilisateur des tests ;
faciliter la cration, la livraison et la gestion des tests automatiss de
manire s'assurer de leur appropriation par l'quipe charge des
fonctionnalits produit ;
planifier et prendre en compte dans les estimations le travail de
dveloppement de l'automatisation des tests , de manire s'assurer que
les dveloppeurs disposent du temps ncessaire pour le raliser ;
dvelopper des mesures pour s'assurer que l'automatisation est utile (vous
ne pouvez pas amliorer ce que vous ne mesurez pas) ;
valuer constamment si l'automatisation dtecte les dysfonctionnements et
reprendre l'criture des tests automatiss si elle n'en trouve pas.

Pour prendre en charge l'automatisation des tests, l'quipe a dploy IBM Rational Test Workbench
pour les tests fonctionnels et les tests de performances. Pour excuter les tests plus frquemment,
l'automatisation du dploiement des versions intermdiaires de l'application tait essentielle. En
utilisant IBM UrbanCode Deploy, l'quipe a rduit de 90 % les cots de dploiement par le biais du
dploiement automatique de l'application fabrique couvrant galement l'automatisation des
paramtres ncessaires d'application et de configuration de serveur de base de donnes.

VII-D-3. Crer un pipeline de livraison

L'quipe IBM SWG dcida de crer un pipeline de distribution amliorant l'usage des outils comme
services afin de permettre aux dveloppeurs de valider le code, de le tester et de le dployer
dans un environnement de production en quelque 60 minutes au lieu d'un ou deux jours
auparavant. Ce processus a permis de rduire les retours en arrire et d'optimiser la productivit.

L'quipe de dploiement dtermina qu'un pipeline de distribution continue ncessitait d'appliquer

les meilleures pratiques suivantes :

excuter les tests au plus tt ( Shift-left ) et automatiser au maximum ;

utiliser le mme mcanisme de dploiement sur tous les environnements ;

s'efforcer de maintenir constamment l'application en attendant d'tre livre
aux utilisateurs ;
traiter l'infrastructure comme une infrastructure programmable.
L'illustration 6-1 montre les produits et les fonctions fournis dans le cadre du pipeline de livraison
continue adopt par IBM SWG.

Illustration 6-1 : le pipeline de distribution continue.

Une meilleure pratique essentielle de l'implmentation d'un pipeline de livraison continue est de
traiter l'infrastructure comme une infrastructure programmable . Cela implique que le
dveloppeur peut crire des scripts pour configurer l'infrastructure requise pour l'application dans
le code de cette dernire. Auparavant, cela tait ralis gnralement par un administrateur
systme ou une personne charge des oprations, mais dsormais avec le contrle et les gains
d'efficacit que cela apporte, le dveloppeur peut le faire directement. Puppet, Chef et IBM
UrbanCode Deploy with Patterns sont des exemples des nouvelles catgories d'outils
d'automatisation qui font de l'infrastructure programmable une ralit concrte.

Dsormais, l'quipe d'IBM SWG traite son infrastructure comme une infrastructure programmable
et suit ces meilleures pratiques :

traiter les dfinitions de modles de dploiement, les packages de scripts et

les services comme du code ;
versionner tout ;
automatiser le dploiement des modles de topologie vers le cloud ;
grer les versions de modles dans plusieurs environnements cloud ;
automatiser les tests des modles ;
nettoyer les ressources de catalogue pour viter la propagation.

VII-D-4. Exprimenter rapidement

Le concept de livraison continue couvre non seulement les activits de dveloppement, telles que
l'intgration continue et le dploiement continu, mais galement l'activit plus fondamentale
d'apprentissage qui peut tre ralise de manire optimale via l'exprimentation et la mesure de
rsultats.

Lorsque des fonctionnalits ou des services sont ajouts une application, vous n'tes pas sr que
le client en tirera les avantages escompts. C'est la raison pour laquelle IBM considre qu'il est
important d'exprimenter en amont et souvent, de demander aux clients des retours sur les
fonctionnalits qui leur conviennent et de supprimer celles qui n'offrent que peu d'avantages ou qui
peuvent peut-tre mme prsenter un problme. Cette stratgie est dcrite dans le diagramme de
l'illustration 6-2.
Illustration 6-2 : le dveloppement reposant sur l'hypothse.

L'quipe d'IBM SWG s'est enrichie de l'exprimentation frquente et a dvelopp les meilleures
pratiques suivantes :

dfinir des mesures et des critres de succs/d'chec ;

dterminer ce qui fonctionne par exprimentation des petits tests par un
petit groupe d'utilisateurs afin de dterminer l'utilit d'une fonctionnalit ;
lancer en continu plusieurs exprimentations ;
prendre rapidement des dcisions partir de faits ;
distribuer rapidement pour exprimenter plus rapidement ;
crer un mcanisme pour permettre l'exprimentation au niveau du systme
(Google Analytics, IBM Digital Analytics, etc.) ;
envisager diffrents modles d'exprimentation (tests A/B classiques, MAB
MultiArmed Bandit, etc.) ;

suivre deux chemins simultanment pour les projets associs : exprimenter

sur un projet cloud et utiliser les donnes des exprimentations pour, non
seulement dterminer la direction du projet sur le cloud, mais galement
celle des projets associs sur site.

VII-D-5. Amliorer en continu

IBM SWG voulait crer une culture d'amlioration continue et exploiter des mesures d'efficacit et
d'efficience pour s'en assurer. Les quipes grent leurs efforts d'amlioration continue comme un
projet Agile. Dans ce contexte, l'amlioration continue repose sur le suivi des objectifs de maturit,
des difficults et des actions d'amlioration associes pour rsoudre les problmes. Les quipes
suivent le travail d'amlioration continue comme n'importe quel autre travail de dveloppement
pour que l'investissement soit largement partag par tous. Le dveloppement et l'adoption de ces
objectifs de maturit (par exemple, les capacits d'amlioration) peuvent prendre un ou plusieurs
trimestres. La rduction ou l'limination des problmes importants peuvent prendre de nombreux
mois. Mais dans tous les cas, les actions d'amlioration spcifiques doivent tre toutes adaptes
pour pouvoir tre ralises dans le dlai d'un mois.

IBM SWG utilise les rtrospectives pour institutionnaliser l'amlioration continue. Une rtrospective
est la vrification rgulire de ce qui a fonctionn, de ce qui n'a pas fonctionn et des actions qui
doivent tre menes pour procder des amliorations. Si vous n'utilisez pas de rtrospectives,
cela implique qu'un niveau de perfection dans le dveloppement de logiciel n'a pas encore t
atteint. Dans les grandes quipes, il peut exister une hirarchie de rtrospectives. Pour IBM SWG,
chaque quipe charge d'un composant excute une rtrospective, et ces rtrospectives sont prises
en compte dans les rtrospectives du niveau de l'application qui sont ensuite elles-mmes prises en
compte dans les rtrospectives de niveau produit. Les actions des rtrospectives sont documentes
avec les difficults et les actions d'amlioration continue excuter pour les rduire ou les
liminer.

Et pour s'assurer que les quipes travaillent plus efficacement, l'quipe d'IBM SWG a dfini des
mesures mtier et des mesures oprationnelles afin de dterminer l'efficacit de la transformation
DevOps. Les mesures mtier sont constitues d'amliorations mesures dans les domaines
suivants :

acclration de la livraison ;
amlioration de la satisfaction du client ;
rduction des cots de maintenance tout en augmentant les investissements
dans l'innovation ;
accroissement de l'adoption client.

Les mesures oprationnelles ont un impact sur l'efficacit de l'quipe dans le

temps et mesurent les lments suivants :

dlai de lancement d'un nouveau projet ;

dlai de fabrication ;
dlai des tests d'itration.

VII-E. Les rsultats de DevOps

Une approche DevOps a permis l'quipe d'IBM SWG d'obtenir des gains significatifs au niveau de
l'amlioration de la satisfaction client et d'une meilleure adoption client et, finalement, de connatre
une croissance deux chiffres de son chiffre d'affaires. Les dlais plus courts ont stimul les
quipes de livraison au sein d'IBM, ce qui s'est traduit par des livraisons plus rapides des mises
jour des solutions sur site, ainsi que la livraison de nouveaux services cloud, tels Bluemix, DevOps
Services for Bluemix ou Collaborative Lifecycle Management as a Managed Service (CLM aaMS).

L'illustration 6-3, un exemple du succs de l'approche DevOps chez IBM, montre les rsultats
mesurs atteints par l'quipe produit IBM SWG Rational Collaborative Lifecycle Management.

Illustration 6-3 : Amliorations mesures de l'quipe IBM SWG.

VIII. Chapitre7 : Les dix mythes de DevOps

Dans ce chapitre :

quoi sert DevOps ;

quoi ne sert pas DevOps.
DevOps est un mouvement rcent qui continue d'merger, notamment dans les entreprises.
l'instar de n'importe quel mouvement ou n'importe quelle tendance, il fait natre des mythes et des
illusions. Certains de ces mythes peuvent provenir de socits ou de projets qui ont tent d'adopter
DevOps et qui ont chou. Ce qui peut tre vrai dans un cas peut ne pas tre ncessairement vrai
dans un autre. Voici quelques-uns des mythes courants sur DevOps et les faits.

VIII-A. DevOps s'adresse uniquement aux entreprises nes sur le

Web .

Ce que l'on appelle gnralement DevOps, provient des entreprises nes sur le Web (socits
qui proviennent d'Internet), telles que Etsy, Netfix et Flickr. Cependant, les grandes entreprises
utilisent des principes et des pratiques DevOps pour distribuer les logiciels depuis des dizaines
d'annes. En outre, les principes DevOps actuels, dcrits dans ce manuel, se caractrisent par un
niveau de maturit qui permet de les appliquer aux grandes entreprises disposant de technologies
multiplateformes et d'quipes rparties.

VIII-B. DevOps vise apprendre aux quipes des oprations

programmer

Les quipes d'oprations crivent depuis toujours des scripts pour grer les environnements et les
tches rptitives, mais avec l'volution de l'infrastructure programmable, ces quipes ont eu
besoin de grer ces normes volumes de code avec les pratiques de l'ingnierie logicielle, telles
que la gestion de version de code, le check-in, le check-out, le dveloppement en parallle et la
fusion. Actuellement, une nouvelle version d'un environnement est gnre par un membre d'une
quipe d'oprations en crant une nouvelle version du code qui la dfinit. Cependant, cela
n'implique pas que les quipes des oprations doivent apprendre coder en Java ou C#. La plupart
des mthodologies d'infrastructure programmable utilisent des langages tels que Ruby qui sont
relativement simples matriser, notamment pour les personnes qui savent crer des scripts.

VIII-C. DevOps s'adresse uniquement aux quipes de dveloppement et

des oprations

Bien que le terme laisse penser qu'il concerne le dveloppement et les oprations, DevOps
s'adresse toute l'quipe. Toutes les parties prenantes dans la livraison de logiciel les mtiers,
les utilisateurs, le management, les partenaires, les fournisseurs, etc. sont concernes par
DevOps.

VIII-D. DevOps n'est pas fait pour les entreprises ITIL

Certaines personnes craignent que les fonctionnalits DevOps, telles que la livraison continue, ne
soient pas compatibles avec les vrifications et les processus prescrits par ITIL (Information
Technology Infrastructure Library), un ensemble de meilleures pratiques pour la gestion des
services informatiques. En fait, le modle de cycle de vie ITIL est compatible avec DevOps. La
majorit des principes dfinis par ITIL sont parfaitement compatibles avec les principes DevOps.
Cependant, ITIL ptit d'une mauvaise rputation dans certaines organisations du fait de son
implmentation avec des processus Waterfall lents qui ne permettent pas d'effectuer rapidement
des modifications et des amliorations. L'alignement des pratiques entre les quipes de
dveloppement et des oprations est l'essence mme de DevOps.

VIII-E. DevOps n'est pas adapt aux secteurs rglements

Les secteurs rglements ont un besoin global de vrifications et protection et s'assurer de

l'approbation des parties prenantes charges de la conformit et de l'audit. L'adoption de DevOps
amliore la conformit s'il est appliqu correctement. L'automatisation des flux de processus ainsi
que l'utilisation d'outils disposant de fonctionnalits intgres pour enregistrer les informations
d'audit peuvent tre bnfiques.
Les organisations dans les secteurs rglements auront toujours des points de contrle ou points
de passage ncessitant des interventions manuelles, mais ces lments ne sont pas incompatibles
avec DevOps.

VIII-F. DevOps n'est pas fait pour les dveloppements externaliss

Les quipes externalises doivent tre considres comme des prestataires ou des fournisseurs de
fonctionnalits alimentant le pipeline de distribution DevOps. Cependant, les entreprises doivent
s'assurer que les pratiques et les processus des quipes des fournisseurs sont compatibles avec
ceux de leurs quipes de projet internes.

L'utilisation d'outils communs de planification de versions, de gestion des lments de travail et de

rfrentiel d'actifs amliore de manire significative la communication et la collaboration entre les
quipes mtier, les fournisseurs et les quipes projet, et elle permet d'appliquer les pratiques
DevOps. L'utilisation d'outils de gestion de versions d'applications peut amliorer considrablement
la capacit d'une organisation dfinir et coordonner l'ensemble du processus de sorties de
versions entre tous les participants.

VIII-G. Pas de DevOps sans cloud

Quand on pense DevOps, on pense souvent au cloud du fait de sa capacit provisionner

dynamiquement les ressources d'infrastructure pour les dveloppeurs et les testeurs, ce qui permet
d'obtenir rapidement des environnements de test sans attendre des jours/semaines la rponse
positive une demande manuelle. Cependant, le cloud n'est pas ncessaire pour adopter les
pratiques DevOps ds lors qu'une organisation dispose de processus efficaces pour provisionner les
ressources ncessaires aux dploiements et tests des nouvelles modifications de l'application.

La virtualisation est facultative. Le dploiement continu vers des serveurs physiques est possible si
les serveurs peuvent tre configurs et dploys suffisamment rapidement pour satisfaire les
quipes.

VIII-H. DevOps ne s'applique pas aux grands systmes complexes

Les systmes complexes ont besoin de la discipline et collaboration qu'apporte DevOps. Ces
systmes se caractrisent gnralement par des composants logiciels et/ou matriels ayant chacun
leurs propres cycles et jalons. DevOps facilite la coordination de ces cycles de distribution et la
planification des versions au niveau systme.

VIII-I. DevOps est uniquement une affaire de communication

Certains membres de la communaut DevOps ont invent des termes humoristiques, tels que
ChatOps (les quipes effectuent toutes les communications via des outils de communication, tels
qu'Internet Relay Chat) et HugOps (DevOps se concentre uniquement sur la collaboration et la
communication). L'origine de ces termes dcoule, tort, que la communication et la collaboration
peuvent rsoudre tous les problmes.

Certes la communication est un lment important de DevOps, mais une meilleure communication
combine des processus sources de gaspillage n'amliore pas les dploiements.

VIII-J. DevOps est synonyme de dploiement continu des modifications

Cette vision errone provient des organisations qui dploient uniquement des applications.
Certaines de ces entreprises indiquent firement sur leurs sites Web qu'elles dploient tous les
jours en production. Cependant, le dploiement quotidien est non seulement impossible dans les
grandes entreprises qui dploient des applications complexes, mais peut tre galement impossible
du fait des restrictions rglementaires ou de l'entreprise. DevOps ne se limite pas simplement au
dploiement, et certainement pas au dploiement continu vers la production. L'adoption de DevOps
permet aux organisations de mettre en production lorsqu'elles le dcident et non pas en fonction
d'une simple date marque sur un calendrier.

IX. Copyright et licence

DevOps pour les Nuls , 2e dition Limite IBM.

Publi par John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774.
www.wiley.com.
Copyright 2015 par John Wiley & Sons, Inc.

Aucun extrait de cette publication ne peut tre reproduit, stock dans une base de donnes ni
transmis, sous quelque forme ou par quelque moyen que ce soit (lectronique, mcanique,
photocopie, enregistrement, numrisation ou autre), sauf aux conditions autorises aux alinas
107 et 108 du United States Copyright Act de 1976, en l'absence d'autorisation crite pralable de
l'diteur. Les demandes d'autorisation doivent tre adresses par courrier Permissions
Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, par tlphone au
(201) 748-6011, par tlcopie au (201) 748-6008 ou en ligne sur
http://www.wiley.com/go/permissions.

Marques commerciales : Wiley, For Dummies, le logo Dummies Man, The Dummies Way,
Dummies.com, Making Everything Easier et related trade dress sont des marques commerciales ou
dposes de John Wiley & Sons, Inc. et/ou de ses affilis aux tats-Unis et dans d'autres pays, et
ne peuvent pas tre utilises sans l'autorisation crite. IBM et le logo IBM sont des marques
dposes d'International Business Machines Corporation. Toutes les autres marques sont la
proprit de leurs propritaires respectifs. John Wiley & Sons, Inc., n'est associ aucun produit
ou fournisseur cit dans ce manuel.

RESPONSABILIT LIMITE/REJET DE GARANTIE : L'DITEUR ET L'AUTEUR NE PEUVENT TRE

TENUS POUR RESPONSABLES OU N'OFFRIR AUCUNE GARANTIE QUANT L'EXACTITUDE OU LE
CARACTRE COMPLET DU CONTENU DE CET OUVRAGE, ET REJETTENT SPCIFIQUEMENT TOUTES
LES GARANTIES, Y COMPRIS, ET SANS S'Y LIMITER, LES GARANTIES D'ADAPTATION UN USAGE
PARTICULIER. AUCUNE GARANTIE NE PEUT TRE CRE OU TENDUE PAR DES DOCUMENTS
COMMERCIAUX OU PROMOTIONNELS. LES CONSEILS ET STRATGIES DANS CE MANUEL PEUVENT
NE PAS S'APPLIQUER TOUTES LES SITUATIONS. CE DOCUMENT EST VENDU SACHANT QUE
L'DITEUR N'EST ENGAG DANS AUCUN SERVICE DE PRESTATIONS JURIDIQUES, DE
COMPTABILIT OU PROFESSIONNELS. SI UNE ASSISTANCE PROFESSIONNELLE EST REQUISE, IL
EST NCESSAIRE DE FAIRE APPEL AUX SERVICES D'UN PROFESSIONNEL COMPTENT. L'DITEUR
ET LE L'AUTEUR NE PEUVENT TRE TENUS POUR RESPONSABLES DES DOMMAGES RSULTANT DE
L'UTILISATION DU MANUEL. LA RFRENCE UNE ORGANISATION OU UN SITE WEB DANS CE
DOCUMENT SOUS LA FORME D'UNE CITATION ET/OU D'UNE SOURCE POTENTIELLE
D'INFORMATIONS COMPLMENTAIRE N'IMPLIQUE PAS QUE L'AUTEUR OU L'DITEUR APPROUVENT
LES INFORMATIONS QUE L'ORGANISATION OU LE SITE WEB PEUT FOURNIR OU LES
RECOMMANDATIONS QU'ILS PEUVENT COMMUNIQUER. EN OUTRE, LES LECTEURS DOIVENT TENIR
COMPTE DU FAIT QUE LES SITES WEB CITS DANS CET OUVRAGE PEUVENT AVOIR CHANG OU
NE PLUS EXISTER ENTRE LA RDACTION DE CET OUVRAGE ET SA LECTURE.

Pour des informations gnrales sur nos autres produits et services ou sur la manire de crer un
manuel Pour les Nuls pour votre organisation ou entreprise, contactez notre service Business
Development Department aux tats-Unis au 877-409-4177, info@dummies.biz ou visitez le site
www.wiley.com/go/custompub. Pour plus d'informations sur les licences de la marque Pour les Nuls
pour les produits ou les services, contactez BrandedRights&Licenses@Wiley.com.

ISBN: 978-1-119-17743-2 (pbk); ISBN: 978-1-119-17744-9 (ebk)

Fabriqu aux tats-Unis

10 9 8 7 6 5 4 3 2 1