View
217
Download
2
Embed Size (px)
devo
ps
37Dcembre
2014 > Programmez!
Depuis quelques annes, lagilit connat un
essor grandissant dans les DSI. Aujourdhui,
lventail de mthodologies est large et
adaptable tous les contextes. Les valeurs
cls de lagilit sont la collaboration, la
transparence, la culture de la qualit,
ladaptation et la simplicit. De lquipe Scrum
la Feature Team, les transformations agiles
ont convaincu de nombreuses directions de SI
par leur efficacit au sein des quipes de
dveloppement. Lagilit, quand elle nest
applique quau dveloppement, se trouve
nanmoins freine par les tches dexploitation
qui surviennent aprs chaque livraison.
Le but du mouvement DevOps est dabattre
cette frontire en crant une synergie entre les
quipes dexploitation (Ops) et les quipes de
dveloppement (Devs). Traditionnellement, Ops
et Devs ont des objectifs antagonistes : les uns
sont les garants de la stabilit et de la
disponibilit des systmes, l o les autres sont
employs lvolution de ces derniers. Cela
cre un clivage entre ces quipes, appeles
travailler ensemble et tendre vers un mme
objectif : dlivrer le meilleur logiciel aux clients
de lentreprise. De plus, il est courant que les
Ops aient des notions de dveloppement, et
les Devs, dexploitation. Cela entrane
immanquablement des conflits. Quelles soient
bloquantes ou non, ces frictions dgradent la
productivit. Plusieurs symptmes sont
rvlateurs de ces problmes :
En cas de crise, combien de temps faut-il
pour lever une alerte, rcuprer les logs, les
analyser puis identifier la dfaillance ?
Combien de temps pour livrer un correctif en
production ? La rapidit dexcution de ces
actions est fortement lie la qualit de la
coopration entre quipes.
La frquence et la simplicit des mises en
production sont galement des indices
rvlateurs. Les Ops sont rarement impliqus
au dmarrage des projets. Il sensuit des
dlais allongs entre la livraison des
applications et celle des machines qui
serviront de socle. Cela aboutit souvent
une dtection de problmes en pr-
production, seul environnement
suffisamment proche de la production pour
une validation. Les open spaces grouillent
danecdotes du mme acabit. Nous allons
vous guider dans notre vision dune
dmarche damlioration, pour pallier ces
problmes efficacement.
DevOps: dveloppement & productionA travers ce dossier, Xebia vous guide afin que DevOps ne soit pas un buzzword deplus pour vous.
COOPRER
La culture et lorganisation de votre entreprise
sont un pilier de votre transformation vers
DevOps. Les leitmotifs de DevOps peuvent
nanmoins paratre galvauds : qui ne se
targue pas de vouloir travailler de manire
collaborative et en toute transparence ? De ce
fait, quelles sont les implications concrtes sur
lorganisation dun dpartement exploitation
derrire le mouvement DevOps ? Est-ce une
relle rupture ou un simple effet de mode ?
Les organisations de type You build it, you
run it sont sans compromis et semblent un
objectif utopique atteindre pour beaucoup.
Voyons ici quelques axes de travail et les outils
que vous pouvez utiliser pour dmarrer
rapidement une dmarche DevOps sans avoir
rvolutionner votre organisation.
Restaurer la confiance
L'activit des Ops est jalonne de nombreuses
crises. Quelles soient lies des pannes
matrielles ou une mise jour provoquant
une instabilit du systme. Les Ops sont
familiers de la gestion de crise, avec ses
horaires rallonge et ses diagnostics parfois
laborieux. Les bureaux dOps rsonnent
dhistoires croustillantes sur ces Devs
totalement inconscients qui mettent la
production en pril avec des dploiements de
binaires hasardeux. Lun des premiers axes de
progrs est donc de restaurer la confiance
dans un contexte de defiance mutuelle. Pour
ce faire, deux outils sont votre disposition.
Dune part, la conclusion dune mise en
production doit tre lobjet dune runion de
retour dexprience (appele rtrospective)
entre Devs et Ops afin de capitaliser sur les
bonnes pratiques et identifier les points
damlioration. Une pratique rgulire des
rtrospectives devrait diminuer sensiblement le
nombre de crises et restaurer la confiance
entre ces deux protagonistes.
Concevoir des produits
Ops-ready
Les projets agiles manquent souvent dune
vision Ops trs tt dans la conception du
produit. Ce manque est induit par le fait que le
Product Owner, propritaire du backlog, a une
vision mtier centre sur les fonctionnalits
dlivrer lutilisateur. La dimension Ops sera,
au mieux sous-estime, au pire passe sous
silence. Les Ops sont des parties prenantes
dont le PO doit tenir compte. Il est essentiel de
les impliquer ds la constitution du Product
Illu
stra
tio
n X
eb
ia
Illu
stra
tio
n X
eb
ia
032_058-3c_180 18/11/14 00:23 Page37
Backlog. Le Product Backlog reprsente tout
ce qui apporte de la valeur au produit. Des
exigences non fonctionnelles comme certificat
apportent de la valeur, elles doivent apparatre
dans le backlog. Dautres besoins Ops se
traduiront par des critres dacceptation des
user stories. Par exemple, PCA ou scurit.
Anticiper lactivit ops
Une autre difficult pour les Ops est danticiper
les demandes des Devs et les livraisons de
nouveaux binaires. Il nest pas rare de voir des
Devs se plaindre du manque de ractivit des
Ops, et des Ops se plaindre du manque
dorganisation des Devs qui ne savent pas
anticiper leurs besoins. Quelles quen soient
les raisons, les changes sont souvent tendus
et les urgences sont la norme, plus que
lexception. Il suffit parfois de partager un
simple outil de management visuel pour crer
de la transparence sur les travaux en cours
cote Devs et permettre aux Ops danticiper les
demandes. Il est galement possible dinviter
des Ops dans des revues de sprint afin quils
sapproprient le produit avant de voir arriver le
livrable pour mise en production. Cette
dernire pratique est utiliser avec parcimonie
car les Ops sont, en gnral, peu intresss
par le contenu fonctionnel dun sprint.
FLUIDIFIER
Maintenant quune vritable coopration entre
quipes sest installe, les crmonies agiles
mlant Devs et Ops sont prolifiques. Chacun
coute les problmes de lautre. Cela donne
loccasion dharmoniser lensemble :
Dvelopper en accord avec la cible quest
lenvironnement de production.
Adapter, dans la mesure du possible, le SI
aux besoins des dveloppeurs.
De plus en plus de structures ont russi cette
transition. Du rapprochement entre les quipes
sont ns de nombreux outils dautomatisation.
Le but de ces outils, que nous allons voir plus
en dtail, est de transformer le SI en un self-
service pour dveloppeurs, gr par les Ops.
Usine logicielle
Premire tape de tout projet : la mise en
place des outils de dveloppements. Il faudra
une quipe :
Un dpt de code versionn
Git ou Mercurial rempliront le job sans
difficult. Ils permettent tous deux de faire des
commits locaux aux machines des
dveloppeurs avant denvoyer leur travail par
paquet au dpt central. Cela leur donnera la
possibilit de faire des commits plus petits et
donc, de rduire grandement les problmes de
merge en intgrant leur code au tronc
commun.
Il doit tre possible pour nimporte quel
dveloppeur de crer de nouveaux dpts
simplement. Pour cela, des outils comme
GitLab, GitBlit ou RhodeCode vous offriront
une interface Web de gestion des utilisateurs
et des dpts de code.
Un serveur dintgration continue
Jenkins, de par sa simplicit dusage et ses
nombreux plugins, est tres populaire. Vous
pourriez galement regarder TeamCity ou
Bamboo pour dterminer quel outil vous
convient le mieux. Tous ces outils sont
galement disponibles en Service Cloud pour
vous viter de les mettre en place en interne et
gagner en vitesse de mise en place.
Un dpt dartefact
En fin de build, les artefacts produits doivent
tre stockes pour servir aux processus de
dploiement. L, le choix est extensif en
fonction de votre approche :
Si votre intgration continue dlivre des
fichiers WAR ou un autre artefact type Java, un
dpt Maven tel que Archiva ou Nexus est
conseiller.
Si vous souhaitez pousser lintgration
continue produire des paquets systmes
Linux (des .deb ou des .rpm par exemple), il
faudra alors adopter le mode de distribution
ad-hoc.
Dans tous les cas, lessentiel est davoir au
moins lquivalent dun serveur FTP, ou vous
stockerez les artefacts en les rangeant
correctement par numros de version.
Infrastructure
La mise en place de linfrastructure doit passer
par des outils de provisionnement
automatique, comme VMWare Cloud Template
ou AWS CloudFormation. Cela implique bien
sur davoir un socle de virtualisation qui
permette de scripter le dmarrage des
ressources.
La virtualisation des diffrents
environnements, du dveloppement la
production, garantit :
Une bonne ract
