devops : développement & production

Download DevOps : développement & production

Post on 05-Jan-2017

217 views

Category:

Documents

2 download

Embed Size (px)

TRANSCRIPT

  • 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