DevOps : développement & production

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